IPP Mail Archive: Re: IPP> NOT - ISSUE 05 [return successful

IPP Mail Archive: Re: IPP> NOT - ISSUE 05 [return successful

Re: IPP> NOT - ISSUE 05 [return successful-ok-events-complete']

From: Michael Sweet (mike@easysw.com)
Date: Wed Aug 01 2001 - 08:22:24 EDT

  • Next message: KONKAR HARDWARE VENTURES INT.: "IPP> Computer hardware supply."

    "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
    when returning an error (client-error-not-found, for example) or when
    are not using wait mode. b) above supports that proposal, while c)
    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@easysw.com
    Printing Software for UNIX                       http://www.easysw.com

    This archive was generated by hypermail 2b29 : Wed Aug 01 2001 - 08:26:24 EDT