In the 1st paragraph of this message you say: "...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..."
In the 2nd paragraph you suggest different schemes, ports and methods.
While I'm not yet taking a position on these additions, it seems to me that make
an IPP notification completely different from normal HTTP operations is 100%
completely contrary to the part of the 1st paragraph noted above. Either we
want it to go through firewalls easily or we want it to be as different as
possible from normal HTTP (or maybe somewhere in between) but these are at
opposite ends of the spectrum.
**********************************************
* Don Wright don@lexmark.com *
* Chair, Printer Working Group *
* Chair, IEEE MSC *
* *
* Director, Strategic & Technical Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************
hastings%cp10.es.xerox.com@interlock.lexmark.com on 11/03/99 09:43:11 PM
To: ipp%pwg.org@interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: IPP> NOT - How about using a new HTTP method for the "IPP Notification
Delivery Protocol over HTTP"
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