Greetings.
Can the spec of the ippget event notification delivery method please be
changed so that an implementation can either support only pull mode, or can
drop to pull mode as needed? An implementation might only be able to
support a limited number of simultaneous connections.
It seems to me that the way the spec is currently proposed, if the printer
receives a Get-Notifications request with notify-no-wait set to false or
omitted, if the printer doesn't want to tie up a socket, it must return
server-error-busy which I assume means it cannot at the same time return
any events, but please correct me if that assumption is wrong. It seems to
me that a new error code is needed that tells the client that it is too
busy for push mode, but that if the request is made again with
notify-no-wait set true, it would be honored. Even better, please add a
status code like successful-ok-too-busy-for-no-wait, so that the events can
at the same time be returned.
Another change I would like to this spec is removal of
client-error-not-found as a possible status code returned by a
Get-Notifications request. When a job ends that had per-job subscriptions,
those subscription objects will be deleted, but there could be event
notification objects that had been created by those subscriptions that will
last for some amount of time. Just because the subscription objects are
gone shouldn't mean the client cannot receive the events.
Finally, please explain why redirection-other-site would be used, and why
it wouldn't apply to all IPP requests. Thanks.
Regards,
Marty Joel
This archive was generated by hypermail 2b29 : Wed Jul 11 2001 - 02:35:55 EDT