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
At 08:26 12/05/1997 PST, Carl Kugler wrote:
>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
>
>