Michael,
I goofed in my reply about case (b) returning the "notify-get-interval".
Case (b) returns the new 'successful-ok-events-complete' status code and
MUST NOT return the "notify-get-interval" as you have pointed out (and is
the way we wrote up the complete proposal).
I also agree that we need to be very clear and explicit, so this back and
forth is good to get it right.
I should have said about case (b):
TH> Our intent of the proposed resolution of ISSUE 05 was (b), except for
the "close the connection" part. The Printer doesn't close the connection.
If the Printer sends back a response and immediately closes the connection,
the response may not get to the client. The Printer just returns the
'successful-ok-events-complete' status code to the client which is a hint to
the client that the client should consider closing the connection (after
getting the response). Otherwise, the Printer MAY close the connection if
connections are getting tight. However, both the client and the Printer MAY
keep the connection open, just as for any IPP operation and the client MAY
try a Get-Notifications operation (or any other operation) any time later.
You've indicated agreement on not saying that the Printer closes the
connection.
So I think we are in agreement on case b being the desired behavior,
correct?
Thanks,
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Wednesday, August 01, 2001 05:22
To: Hastings, Tom N
Cc: McDonald, Ira; ipp (E-mail); ipp at webpageassembler.com
Subject: Re: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']
"Hastings, Tom N" wrote:
> ...
> TH> Our intent of the proposed resolution of ISSUE 05 was (b), except for
> the "close the connection" part. The Printer doesn't close the
connection.
> If the Printer sends back a response and immediately closes the
connection,
> the response may not get to the client. The Printer just returns the
> "notify-get-interval" to the client which is a hint to the client that the
> client should consider closing the connection (after getting the
response).
OK, but that's not what I had in b):
> b) close the connection, returning the
> successful-ok-events-complete status without a
> notify-get-interval attribute to tell the client when
> to retry (because a new subscription might be created
> for that recipient),
The current proposed change says that you only return the
notify-get-interval
when returning an error (client-error-not-found, for example) or when
you
are not using wait mode. b) above supports that proposal, while c)
below
defines a slightly different behavior for the wait mode when only the
notify-recipient-uri is provided:
> c) close the connection, returning the
> client-error-not-found status with a
> notify-get-interval attribute, just like an
> initial Get-Notifications request.
I know I'm nitpicking, but the current spec is vague enough on these
special cases that we need to clarify things so it can be implemented
consistently. We need to implement ippget consistently because it
is the most likely candidate for client implementations and will be
important for IPPFAX... The spec needs to be clear enough that it is
obvious that the spec requires "if a then b else c"...
> Otherwise, the Printer MAY close the connection if connections are getting
> tight. However, both the client and the Printer MAY keep the connection
> open, just as for any IPP operation and the client tries the
> Get-Notifications operation after "notify-get-interval" seconds.
Right, my choice of "close the connection" was incorrect and should have
been "finish the response" or something along those lines.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com