IPP Mail Archive: IPP> ippget status codes

IPP> ippget status codes

From: Marty Joel (mjoel@netreon.com)
Date: Mon Jul 23 2001 - 20:04:37 EDT

  • Next message: Erik Guttman: "RE: IPP> FW: [Srvloc-discuss] [Multiple registrations for a single print device]"

    Michael Sweet <mike@easysw.com>@pwg.org on 07/23/2001 02:10:19 PM

    Sent by: owner-ipp@pwg.org

    To: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
    cc: mjoel@netreon.com, ipp@pwg.org

    Subject: Re: IPP> ippget Design Needs Work [use multi-part/related?]

    Hi Michael,

    "Michael Sweet" wrote:

    > "Hastings, Tom N" wrote:
    > > ...
    > > 4. Which leaves how to indicate that this is really the last response,
    > > i.e., that there are no more Subscription objects left that match?
    Marty
    > > Joel suggests that there be a completely separate response part with
    its
    > > own status code. The status should be the 'client-error-not-found'
    which
    > > is the status returned when there are no Subscription Objects found,
    > > whether this is the first Get-Notifications response or the last.
    >
    > This will work, although it won't indicate if the subscription has run
    > out or just been cancelled, and it doesn't cover the situation if you
    > do a Get-Notifications with wait=false - i.e. you are only getting a
    > single part, and there are events, but how do you know if you need to
    > ask again?
    >
    > How about adding a status code called
    > "successful-ok-subscription-expired", which will be returned by
    > Get-Notifications when the subscription has no more events and has
    > expired?
    >
    > That way if a subscription is cancelled *while* a client is waiting
    > on more event messages, the client will see a different status code
    > (client-error-not-found) and can display a suitable error/warning
    > message, vs. seeing that a job has completed because of the
    > "successful-ok-subscription-expired" status?

    Good point about returning a different status code for different
    situations. I think that if subscriptions expire (or are cancelled) such
    that there are no subscriptions that match the waiting Get-Notifications,
    it should return client-error-not-found, just as it would have replied
    immediately if Get-Notifications was requested with no matching
    subscriptions. To me, the second situation is where the printer chooses to
    end the waiting, in which case it could return server-error-busy with a
    notify-get-interval.

    Marty



    This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 20:12:19 EDT