I must admit I was "thinking out loud" about this, trying to understand it. Also, I'm relatively new to
IPP and I missed the exchange you refer to in #1; could you point me to it in the archives so I can
review it?
I didn't mean to suggest removing the Validate-Job operation; just the words in the model document
that say "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 thought that IF servers
returned error status without waiting to receive the document data, and IF clients monitored for error
status while transmitting the request, it might be more efficient to just send the Print-Job and avoid
the round trip for the Validate-Job. There's also a little window there between the Validate and the
Print during which it's possible that conditions could change on the Printer.
If the IPP operation and attributes were sent in a separate HTTP "chunk" before the document data,
would that make it easier for the server to return a response before receiving the entire HTTP
request? I guess that's really an HTTP question, or a web server implementation question.
Finally, after peeking for the first time at Section 8.2, Message Transmission Requirements, in
INTERNET-DRAFT HTTP/1.1 Friday, November 21, 1997, at
http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-01.txt, I wish to withdraw my
suggestion that IPP make use of the 100-Continue response to notify the client that a PrintJob has been
validated, continue sending document data.
-Carl
|Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger,
> Tom Hastings (hastings at cp10.es.xerox.com)
> 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
>> 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
> >
> >
>> * Next message: Ron Bergman: "Re: IPP> A free IPP test suite to be available!"
> * Previous message: Roger K Debry: "Re: IPP> MOD - Updated Section 15.3 from Bob, Scott, Roger,"
http://www.pwg.org/hypermail/ipp/2889.html