IPP Mail Archive: Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger,

Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger,

Carl Kugler (kugler@us.ibm.com)
Fri, 5 Dec 1997 11:26:40 -0500

I have a comment about this section:

15.3 Suggested Operation Processing Algorithm for all operations
...
In the following algorithm, processing continues step by step until a "=
RETURNS
the xxx status code *(" statement is encountered. Error returns are in=
dicated
by the verb: "REJECTS". Since clients have difficulty getting the stat=
us code,
before sending all of the document data in a Print-Job request, clients=
SHOULD
use the Validate-Job operation before sending large documents to be pri=
nted, in
order to validate whether the IPP Printer will accept the job or not.

I think that this use of the Validate-Job operation might be redundant,=
since
HTTP/1.1 already provides a mechanism for this kind of thing:

o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
the network connection for an error status while it is transmitting
the request. If the client sees an error status, it SHOULD
immediately cease transmitting the body. If the body is being sent
using a "chunked" encoding (section 3.6), a zero length chunk and
empty footer MAY be used to prematurely mark the end of the
message. If the body was preceded by a Content-Length header, the
client MUST close the connection.
...
o An HTTP/1.1 (or later) client MUST be prepared to accept a 100
(Continue) status followed by a regular response.
...
100 Continue
The client may continue with its request. This interim response is
used to inform the client that the initial part of the request has
been received and has not yet been rejected by the server. The clien=
t
SHOULD continue by sending the remainder of the request or, if the
request has already been completed, ignore this response. The server=

MUST send a final response after the request has been completed.

So, the IPP object SHOULD process and validate the request up to step 1=
5.4.8,
then send either a "100 Continue" or an error response to the client, b=
efore
waiting to receive the document data. The client should SHOULD monitor=
the
network connection for an error status while it is transmitting the req=
uest. If
the client sees an error status, it SHOULD immediately cease transmitti=
ng
document data. Since we should do all this anyway for HTTP/1.1, maybe =
we don't
need the separate Validate-Job step?

Side question: does an IPP error response have an HTTP status code of
Successful "200 OK"?

Carl Kugler
=