Looks like your thoughts and Keith Moore's thoughts are the same on these
issues for the "IPP Notification Delivery Protocol over HTTP" document.
Tom
-----Original Message-----
From: Hugo Parra [mailto:HPARRA@novell.com]
Sent: Thursday, November 04, 1999 21:34
To: hastings@cp10.es.xerox.com; ipp
Subject: Re: IPP> NOT - How about using a new HTTP method for the "IPP
NotificationDelivery Protocol over HTTP"
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@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