Tom,
I'm in favor of assigning a new url scheme (e.g., ipp-ntfy://) and default port number to this protocol. Having this additional control might encourage administrators to allow some of this communication to flow across some firewalls (especially in the case where a printer uses the protocol to communicate with a notification service with a well-known address inside a firewall, which in turn can "fan-out" notifications within its intranet.)
I believe defining and using a different HTTP method will not help but detract from this goal as it might require the existence of firewalls and proxies that understand the new method.
I still maintain that the IPP Notification Delivery Protocol over HTTP is a different protocol than IPP. Its intended use is different from IPP (a strictly client-server protocol). When I come across an "ipp://..." url, in ANY context, I'd like to be certain that it represents a printer (we've informally. at least in practice, deprecated ipp job URIs).
-Hugo
>>> "Hastings, Tom N" <hastings at cp10.es.xerox.com> 11/03/99 07:43PM >>>
Hugo,
In your proposal for the "IPP Notification Delivery Protocol over HTTP", we
need to do whatever we can to make it most likely that fire wall
administrators will allow the notifications to flow out across the firewall
that contains the IPP Printer AND flow across the firewall that contains the
Notification Recipient.
In addition to using a new scheme (ipp-ntfy) and a new default port (???),
how about also using a new HTTP method for the "IPP Notification Delivery
Protocol over HTTP"? Perhaps we could call the new method "notify" or
"send-notifications".
Tom