I feel we've lost the way a little talking about dial-in connections. To me
>4. Users configures fax to auto answer when someone calls (probably a
>default condition)
sounds a lot like the fax analog of going from:
>3. Internet fax B is NOT online. Ooops. Now what
to:
>4. Or Internet B is online (we happen to catch it while it is dialed up),
>so Internet fax B responds with G3 or G4 then waits
I didn't think that we would be talking about the problems of dial-up when
we were considering this protocol, rather that the dial-up problem would be
resolved by other standards. It feels like we're discussing a new file
transfer protocol (let's call it FTP) and considering what to do if the
FTPD is accessible only via a dial-up connection. It doesn't seem like it
enters into the equation; we're seriously mixing layers here.
The same question with good old fax would be: what do I do if the receiver
isn't set to autoanswer? And the usual response is ... retry for a
reasonable period and then fail. If the owner of a QualDocs server cannot
keep his server online then it's got to be his problem, just as it would be
for a shared-line fax where the fax isn't always set to autoanswer. If he
wants to receive faxes even though he's not connected, then maybe it would
be better for him to use EIFAX or IFAX store and forward in this case,
requiring an IPP-based client to use a gateway to get there?
HTTP and IPP both assume that they will be able to connect to the server,
and will return an error if this is not accomplished. Since we're riding on
top of (or alongside) IPP we could recommend that implementations use a
retry scheme if the server isn't available.
Cheers,
Nick Webb