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).=20
-Hugo
>>> "Hastings, Tom N" <hastings@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