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

From: Carl Kugler <[email-masked]>
Date: 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 indicated
by the verb: "REJECTS".  Since clients have difficulty getting the status 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 printed, 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 client
   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 15.4.8,
then send either a "100 Continue" or an error response to the client, before
waiting to receive the document data.  The client should 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
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

---

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Dec 1997 07:37:43 PST

Carl,

I disagree.  We should NOT remove Validate-Job for the following reasons:

1. I had the same language that you propose about returning error status
early and the clients should monitor such returned status, but the
replies on the DL were that that didn't work with HTTP, so I removed
the recommendation that the Printer return an error status as soon
as it detects an error, rather than waiting until the entire document
has been sent.  So there is substantial disagreement with your suggestion
about HTTP.

Could some HTTP experts shed some light on this confusion that we in the
IPP WG have about HTTP?

2. Validate-Job works with any transport protocol.  While we are only
envisioning HTTP as a transport, we are trying to keep the model
independent of the transport.

3. Validate-Job is easy to implement, because its syntax and semantics
are the same as Print-Job, except that no data is sent, no job is created,
no job-id is returned, and no job status attributes are returned.

4. Validate-Job is a MANDATORY operation, so a client can count on it
being implemented by all IPP Printers.  An IPP client cannot count on
the behavior you describe with all HTTP servers, so it is more likely to
work for a client to use a Validate-Job before sending a big document
with Print-Job.  If the document is small, the client can skip the 
Validate-Job step if it wants to.  Also if the client doesn't care
about response, it can always skip the Validate-Job, no matter how big
the document is.

Tom