Carl Kugler wrote:
> ...
> for user confirmation. The automatic retry SHOULD NOT be repeated if
> the second sequence of requests fails.
>> I would think that IPP POSTs, in general, are non-idempotent, which
> would imply that they should not be automatically retried (in
> general).
I'm not disagreeing with you here; my point is that our IPP servers
must be able to handle broken or limited clients, and that we need
to make sure that the *reason* a POST failed is clear to the client.
[because the convention network printer "wisdom" is to retry until
you know the printer won't take the job]
I'm not sure what the current implementer's guide says, but our CUPS
client software will do the following:
1. If the connection is refused, retry at regular intervals
until it can be established.
2. If the connection is terminated during a request without a
response then the server has a permanent error with this
job.
3. If the server sends a premature response, close the
connection to the server and handle the error status as
needed.
Basically, I'm planning on seeing broken IPP servers and/or clients
and don't want *our* software to break because of it.
> ...
> I don't see why keeping the connection open means that you can't
> send the error response until after all data has been received.
> That seems inefficient to me. Ideally you'd want to send the error
> response ASAP to get the client to cease transmitting the body.
> ...
Again, I'm not disagreeing here, I'm just being realistic about the
clients that'll be out there.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com