Michael Sweet <email@example.com>@pwg.org on 07/23/2001 02:10:19 PM
Sent by: firstname.lastname@example.org
Subject: Re: IPP> ippget Design Needs Work [use multi-part/related?]
"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?
> > Joel suggests that there be a completely separate response part with
> > own status code. The status should be the 'client-error-not-found'
> > 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
> 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
This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 20:12:19 EDT