Hello,
According to the notification spec, a PUSH is where IPP:
delivers the Event Notification using the Delivery Method and target
address identified
in the Subscription Object's "notify-recipient-uri" attribute if the
Delivery Method
Since that's the definition of push, then I don't think ippget meets the
requirements. Ippget seems more like a long, drawn out pull to me. As I
mentioned in my last email, the so-called push part of ippget is very
difficult to implement.
If I were to redesign ippget to follow the notification spec's definition
of push, it would look like this:
1) When creating an ippget subscription, a new attribute would indicate if
using ippget for push or pull, and that would be stored in the subscription
object.
2) Get-Notifications would be for ippget's pull mode. There would be no
"notify-no-wait". After Get-Notifications returns the events that have
already occurred, it would simply disconnect as IPP does after every other
request.
3) Events objects would only be stored for pull mode. Also, it's my
opinion that event objects should be discarded as soon as they are
delivered, or at least when using reliable delivery methods. Why should a
client see the same event multiple times?
4) When an event for a push-mode ippget subscription occurs, then as the
notification spec says, it would send that event to the client using its
notify-recipient-uri. But how? Push-mode ippget could imply a port the
client will listen to, which of course can be overridden in
notify-recipient-uri. Listening on a port could require network
administrators to have to pierce a hole in their firewalls. If it used
HTTP, which defaults to port 80, the server could send a GET or POST, and
the client would return OK. That will require a port redirector if the
client computer is also a web server.
Sorry to propose changes so late in the specification cycle, but I'm new to
this group, and have discovered ippget's problems only recently.
Regards,
Marty Joel