IPP Mail Archive: IPP> IPPGET Issue 9

IPP Mail Archive: IPP> IPPGET Issue 9


From: Marty Joel (mjoel@netreon.com)
Date: Sat Aug 04 2001 - 04:41:35 EDT

  • Next message: Marty Joel: "Re: IPP> NOT - More about ISSUE 08: Sender MAY include list of subscription ids and sequence numbers"

    Hi all,

    Here are my comments (marked "<MJ>") added to Michael Sweet's comments
    (marked "MS>").

    Marty Joel

    "Hastings, Tom N" wrote:
    > ISSUE 09: Make Event Wait Mode OPTIONAL for a Sender and a Receiver?
    > Currently the spec REQUIRES the Receiver to support both values of the
    > "notify-wait" operation attribute ('true' and 'false').
    > With the Notification Recipient being able to request the Receiver to
    > out duplicates, is it ok to allow the Receiver to always force the
    > Notification Recipient back to Event No Wait Mode with the
    > "notify-get-interval" operation attribute of when to poll next?
    > Of should Event Wait Mode be RECOMMENDED for the Receiver?
    > What about RECOMMENDED for the Sender?
    > ...

    MS> I think event-wait-mode should be OPTIONAL but RECOMMENDED. There
        will always be client and server implementations that can't do the
        multipart encoding, or can't spare the extra socket resources.

    MS> Since we already have defined the fallback behavior for both client
        and server, this should not pose a problem.

    MS> It might be useful to provide a new "notify-wait-supported"
        attribute that the client can query with the Get-Printer-Attributes
        request to see ahead of time if the server can support wait mode,
        although with the caveat that the server may choose not to honor
        individual requests in the interests of resource management.

    <MJ> I like the idea of making Event Wait Mode RECOMMENDED for both the
         Sender and Receiver. I don't know if notify-wait-supported is needed,
         since I don't see how that would change the Sender's behavior. Does
         the Sender care if it sends a request for wait mode and receives a
         try-again time, versus sending a non-wait mode and receives a

    <MJ> Regarding the whole try-again time issue, I don't think the Receiver
         should be sending that, and should indicate the desire to stop or not
         start wait mode with a boolean or a status code. The Sender can do a
         Get-Printer-Attributes to learn how long events are retained. The
         Sender knows by when it must issue another Get-Notifications to avoid
         the risk of losing events. If it isn't in keep-alive mode, the Sender
         must take into account how long it might take to connect, so the
         returning of the number of seconds to wait before trying again is

    This archive was generated by hypermail 2b29 : Sat Aug 04 2001 - 04:44:40 EDT