Subject: IPP> Notifications

From: Paul Moore <[email-masked]>
Date: Tue, 3 Feb 1998 10:51:15 -0800

Has anybody noticed that IPP will be useless for notifications due to the
asymmetry of the protocol? As currently constituted a printer cannot send an
unsolicted message to anybody. 

Was this discussed later on on the Thursday brainstorm?

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 3 Feb 1998 11:29:28 -0800

Yes, this was discussed. Several solutions were proposed. Check out the
minutes of the IPP meeting that Don just posted.
I think some of the ideas were included in the minutes.

Randy

	-----Original Message-----
	From:	Paul Moore [SMTP:[email-masked]]
	Sent:	Tuesday, February 03, 1998 10:51 AM
	To:	[email-masked]'
	Subject:	IPP> Notifications

	Has anybody noticed that IPP will be useless for notifications
due to the
	asymmetry of the protocol? As currently constituted a printer
cannot send an
	unsolicted message to anybody.

---

From: Paul Moore <[email-masked]>
Date: Tue, 3 Feb 1998 13:05:03 -0800

The minutes dont really discuss it. There is talk about email vs 'IPP
notifications' But no real discussion of how IPP notification could be done.
A device-level protocol that does not allow Out of band feedback seems
pretty broken 

> From:	Turner, Randy [SMTP:[email-masked]]
> Sent:	Tuesday, February 03, 1998 11:29 AM
> To:	Paul Moore; [email-masked]'
> Subject:	RE: IPP> Notifications
> 
>

---

From: Josh Cohen <[email-masked]>
Date: Tue, 3 Feb 1998 15:28:10 -0800

I thought the consensus that the first step was to have
a requirements document written up for IPP.
Since there are many generalized notification efforts
underway ( or soon to be), we can judge the suitability
of using one of them or writing one specific to IPP.
However, that can only be done if we know our requirements
first.

-> -----Original Message-----
-> From: Paul Moore 
-> Sent: Tuesday, February 03, 1998 1:05 PM
-> To: 'Turner, Randy'; [email-masked]'
-> Subject: RE: IPP> Notifications
-> 
-> 
-> The minutes dont really discuss it. There is talk about email vs 'IPP
-> notifications' But no real discussion of how IPP 
-> notification could be done.
-> A device-level protocol that does not allow Out of band 
-> feedback seems
-> pretty broken 
-> 
-> > -----Original Message-----
-> > From:	Turner, Randy [SMTP:[email-masked]]
-> > Sent:	Tuesday, February 03, 1998 11:29 AM
-> > To:	Paul Moore; [email-masked]'
-> > Subject:	RE: IPP> Notifications
-> > 
-> > 
-> > Yes, this was discussed. Several solutions were proposed. 
-> Check out the
-> > minutes of the IPP meeting that Don just posted.
-> > I think some of the ideas were included in the minutes.
-> > 
-> > Randy
-> > 
-> > 
-> > 	-----Original Message-----
-> > 	From:	Paul Moore [SMTP:[email-masked]]
-> > 	Sent:	Tuesday, February 03, 1998 10:51 AM
-> > 	To:	[email-masked]'
-> > 	Subject:	IPP> Notifications
-> > 
-> > 	Has anybody noticed that IPP will be useless for notifications
-> > due to the
-> > 	asymmetry of the protocol? As currently constituted a printer
-> > cannot send an
-> > 	unsolicted message to anybody. 
-> > 
-> > 	Was this discussed later on on the Thursday brainstorm?
->

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 3 Feb 1998 15:30:11 -0800

Yes, I agree, we need a requirements document first. I can't remember
who had the action item for this.

Randy

	-----Original Message-----
	From:	Josh Cohen [SMTP:[email-masked]]
	Sent:	Tuesday, February 03, 1998 3:28 PM
	To:	Paul Moore; 'Turner, Randy'; [email-masked]'
	Subject:	RE: IPP> Notifications

	-> The minutes dont really discuss it. There is talk about email
vs 'IPP
	-> > 	Has anybody noticed that IPP will be useless for
notifications
	-> > 	asymmetry of the protocol? As currently constituted a
printer

---

From: Carl Kugler <[email-masked]>
Date: Wed, 4 Feb 1998 11:40:42 -0500

> I don't see there is any need for the client to open
> another socket waiting for the server notification.
> Since an IPP connection is persistent, the server can
> notify the client over the same socket any time.

Won't work, unfortunately.  There are a couple problems:

1.  HTTP/1.1 connections only persist for a little while, and that ill-defined
while is likely to be short relative to, say, the time required to process a
print job.  See "HTTP Connection Management" at

 ftp://ietf.org/internet-drafts/draft-ietf-http-connection-00.txt

2.  The client has to be expecting new data to arrive after the initial
response.  If the response has Content-Length, a normal HTTP client will only
read that much content from the connection before the next request is issued.

You might be able to fake around these obstacles by using chunked transfer
encoding in the response.  However, I think this would be considered abuse of
the protocol, and is likely to fail if there are any proxies in the
communication path.

> the server can wait until the same client
> opens another session, provided that the server can
> uniquely identify the client. For completeness, a
> time-to-live for the message may need to be defined.

This could work.  Something like this is allowed by the current IPP model and
protocol.  The client polls with Get-Job-Attributes looking at job-state,
job-state-reasons, and/or job-state-message.  After processing is complete, the
server could wait for a poll for a particular job-id or job-uri before
forgetting the job, with some time-out.  However, nothing in IPP says the
server shall remember the job once it's complete; that's implementation
dependent.

 -Carl  Kugler

[email-masked] on 02/03/98 12:21:17 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc:
Subject: Re: IPP> Notifications

I don't see there is any need for the client to open
another socket waiting for the server notification.
Since an IPP connection is persistent, the server can
notify the client over the same socket any time. If
a notification needs to be sent after the session is
closed, the server can wait until the same client
opens another session, provided that the server can
uniquely identify the client. For completeness, a
time-to-live for the message may need to be defined.

What this means is that if the client is ever interested
in any notification from the server, it should remain
online or check back with the server later.

---

From: Paul Moore <[email-masked]>
Date: Wed, 4 Feb 1998 09:40:34 -0800

This has been actively considered - the main problems are:-

- it is a different protocol with different semantics
- it is a 'best endeavors' protocol, you might or might not get the message
- HTTP was chosen for IPP for its universal reach (firewalls, proxies,
etc.), SNMP is not normally carried as far.

> From:	Caruso, Angelo  [SMTP:[email-masked]]
> Sent:	Wednesday, February 04, 1998 5:30 AM
> To:	Paul Moore; 'Larry Masinter'; Turner, Randy
> Cc:	[email-masked]'
> Paul,
> Has anyone considered using SNMP traps for these kinds of asynchronous
> notifications? It's light-weight and quick and designed for this sort of
> thing, unlike HTTP or email. Just a thought.
> 
> Thanks,
> Angelo
> 
> 	Sent:	Tuesday, February 03, 1998 8:05 PM
> 	To:	'Larry Masinter'; Turner, Randy
> 	Cc:	[email-masked]'
> 	We need to distinguish two types of notification. (This was a
> long and
> 	exciting debate in Maui!).
> 
> 	Firstly a client should be able to request that (for exmaple)
> when a print
> 	job is completed that a human readable notification be sent to
> some URL,
> 	that a pager be bleeped, that a robot arm should waved over a
> fire to create
> 	a smoke signal, whatever.
> 
> 	We also agreed that if IPP were to be extended to manage the
> lower level
> 	interface from the server/cleint to the printer then some
> machine readable
> 	noification mechanism was needed. For example the printer is
> running low on
> 	paper it may signal a listener somewhere, if a configuration
> change takes
> 	place or whatever.  This notification may even be the 'job
> completed'
> 	notification back to a server that triggers it to send the human
> readable
> 	notification that was requested in the original print job from
> the client to
> 	the server.
> 
> 	> From:	Larry Masinter [SMTP:[email-masked]]
> 	> Sent:	Tuesday, February 03, 1998 4:56 PM
> 	> To:	Turner, Randy
> 	> Cc:	Paul Moore; [email-masked]'
> 	> I like the idea of the client supplying, as part of a request,
> 	> the URL for notifications. In email, this address could be
> 	> supplied by the disposition-notification-to header, as with
> any
> 	> kind of receipt notification. For requests that get delivered
> 	> via IPP and POST, the address to which notifications get
> posted
> 	> could be supplied by the client via a URL, too. Clients would
> 	> have to know their own address, though, and make some kind of
> 	> service guarantee that they're willing to listen to responses
> 	> at that address. In some cases, the address of notification
> will
> 	> be different than the client address.
> 	> 
> 	> In email delivery for Internet Fax, we've also wanted to have
> 	> a notification protocol for "successful printing"; I'd like to
> 	> make sure that IPP and Internet Fax don't invent different
> 	> mechanisms for no good reason.
> 	> 
> 	> Larry
> 	> -- 
> 	> http://www.parc.xerox.com/masinter

---

From: Carl Kugler <[email-masked]>
Date: Wed, 4 Feb 1998 12:39:42 -0500

Paul-

I would like to point out that the XML/new method proposal is no better in this
respect.  The problem is not that IPP is asymmetric:  the underlying HTTP
transport layer is asymmetric, and that is common to both approaches.

 - Carl

[email-masked] on 02/03/98 12:24:44 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc:
Subject: IPP> Notifications

---

From: Harry Lewis <[email-masked]>
Date: Wed, 4 Feb 1998 13:18:50 -0500

We need to decide if our investigation should include polling (only) solutions

> time-to-live for the message may need to be defined.

Or if we are seeking a largely event driven scenario with polling as a
fallback.

I prefer the later.

Harry Lewis - IBM Printing Systems

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 4 Feb 1998 10:15:54 -0800

I agree that using SNMP solely for IPP notifications might be too much,
but I still consider the use of UDP datagrams for asynchronous
notification to be valid for the IPP case. And with a simple
acknowledgment scheme you can achieve reliable delivery. I do not think
a server would have to open a TCP connection to a notification receiver
just to send a small notification message; for a notification message I
think TCP is too much as well. UDP datagrams will also scale much better
than TCP connections in the event of a server having to handle a lot of
notification subscriptions.

Randy

	-----Original Message-----
	From:	Paul Moore [SMTP:[email-masked]]
	Sent:	Wednesday, February 04, 1998 9:41 AM
	To:	'Caruso, Angelo '; 'Larry Masinter'; Turner, Randy
	Cc:	[email-masked]'
	Subject:	RE: IPP> Notifications

	- it is a different protocol with different semantics
	- it is a 'best endeavors' protocol, you might or might not get
the message
	- HTTP was chosen for IPP for its universal reach (firewalls,
proxies,
	etc.), SNMP is not normally carried as far.

---

From: Carl Kugler <[email-masked]>
Date: Wed, 4 Feb 1998 14:15:49 -0500

Randy-

UDP datagram notificaton still has the firewalls and proxies problem, unless
everyone goes to SOCKS5.

 -Carl

[email-masked] on 02/04/98 11:53:58 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet
Subject: RE: IPP> Notifications

Randy

---

From: [email-masked] (Philip Thambidurai)
Date: Wed, 4 Feb 1998 14:27:18 -0500

I don't see how a UDP datagram originating from outside the firewall 
     is going to be let inside (without assigning a special port, and 
     security protocol). It is possible to provide a single proxy for the 
     clients which would receive UDP packets from the outside, but this 
     requires extra effort in terms of security admin. and client code.

     In fact, one of the premises behind the firewall policy is to allow 
     only connections that originate inside --- this is going to be 
     problematic for any connectionless async notification --- and argues 
     in favor of the client (or an agent for the client) polling the IPP 
     Printer when desired. --- the notification request must be initiated 
     by the client (which is really not async.)

     SMTP, although somewhat unpalatable, may not be as bad as one thinks. 
     In fact, one could have a very simple smtp "server" (receiver) in the 
     client, so that the mail is relayed directly to the client and does 
     not have to pass through user agents and systems like POP3/IMAP etc.
     However this may be difficult from a policy/administrative view (since 
     mail must be relayed from the company's mail server(s), and possible 
     DNS changes to mx records).

     note that many so-called "push" technologies are really pull (the client or
a daemon polls the external source for information).

     Of course, if we are dealing only with the Intranet, there are many easy 
solutions.

Philip Thambidurai

______________________________ Reply Separator _________________________________
Subject: RE: IPP> Notifications
Author:  "Turner; Randy" <[email-masked]> at INTERNET
Date:    2/4/98 10:15 AM

Randy

---

From: Paul Moore <[email-masked]>
Date: Wed, 4 Feb 1998 12:06:42 -0800

No argument at all. This is othogonal to the XML debate.

I am looking at expanding IPP to cover many needs beyond the relatively
simple feature set currently defined, the extensibility issue led me to the
XML proposal, the unsolicited message issue led me to this thread.

The point I am making is that using HTTP asymmetrically (i.e the client
always POSTs, the printer always listens for POST - which is the 'natural'
use of HTTP) precludes the core IPP protocol from generating asynchronous or
unsolicited reverse messages. This is a major limitiation - I want to be
sure that everybody knows that we are doing it and that we all accept the
trade-off. I'm sure we could invent lots of hacks later on the will work
round this but that's not an ideal solution. What will actually happen is
that we will all poll :-(

> From:	Carl Kugler [SMTP:[email-masked]]
> Sent:	Wednesday, February 04, 1998 9:40 AM
> To:	[email-masked]

---

From: Harry Lewis <[email-masked]>
Date: Wed, 4 Feb 1998 16:09:57 -0500

Philip brings up an important issue which will continue to cloud our
discussion of Notifications unless we understand it.

     >security protocol).

     >Philip Thambidurai

When we discuss notifications, I think some of us have different ideas
based on whether we are thinking primarily Intranet or Internet When thinking
Internet, an e-mail message for job complete is appropriate and acceptable.
Here,
I agree with the recommendations to investigate similar approaches in I-Fax.

If you consider IPP as possibly the most prevalent way to submit print
jobs on ANY network in the future, then I think a much more granular and
streamline method should be considered.

In PWG IPP, we need to address BOTH!

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 4 Feb 1998 13:04:11 -0800

Its very likely that we come to the conclusion to poll; but there is
nothing that says we can't agree on an out-of-bound mechanism to IPP for
event notification, at least I don't think there's a reason. Also,
there's always IPP V2 and possibly another protocol mapping document.

Randy

	-----Original Message-----
	From:	Paul Moore [SMTP:[email-masked]]
	Sent:	Wednesday, February 04, 1998 12:07 PM
	To:	'Carl Kugler'; [email-masked]
	Subject:	RE: IPP> Notifications

	I am looking at expanding IPP to cover many needs beyond the
relatively
	simple feature set currently defined, the extensibility issue
led me to the
	XML proposal, the unsolicited message issue led me to this
thread.

	The point I am making is that using HTTP asymmetrically (i.e the
client
	always POSTs, the printer always listens for POST - which is the
'natural'
	use of HTTP) precludes the core IPP protocol from generating
asynchronous or
	unsolicited reverse messages. This is a major limitiation - I
want to be
	sure that everybody knows that we are doing it and that we all
accept the
	trade-off. I'm sure we could invent lots of hacks later on the
will work
	round this but that's not an ideal solution. What will actually
happen is
	that we will all poll :-(

	> I would like to point out that the XML/new method proposal is
no better in
	> this
due to the
	> asymmetry of the protocol? As currently constituted a printer
cannot send
	> an

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 4 Feb 1998 17:02:56 -0800

I am unconvinced that UDP is unsuitable for an internet solution for
notification. Currently, administrators keep on a tight rein on
applications entering a firewall. Josh stated in the last meeting that
administrators want a finer granularity on what they secure coming in
through firewalls to internal networks. If we define (and register,
through IANA) a particular UDP port for IPP notifications, then if an
administrator wanted to allow this type of service, then he/she would
enable it; just like any other application. 

Randy

	-----Original Message-----
	From:	Harry Lewis [SMTP:[email-masked]]
	Sent:	Wednesday, February 04, 1998 1:10 PM
	To:	[email-masked]
	Subject:	Re: Re[2]: IPP> Notifications

	Philip brings up an important issue which will continue to cloud
our
	discussion of Notifications unless we understand it.

	     >Philip Thambidurai

	When we discuss notifications, I think some of us have different
ideas
	based on whether we are thinking primarily Intranet or Internet
When thinking
	Internet, an e-mail message for job complete is appropriate and
acceptable.
	Here,
	I agree with the recommendations to investigate similar
approaches in I-Fax.

	If you consider IPP as possibly the most prevalent way to submit
print
	jobs on ANY network in the future, then I think a much more
granular and
	streamline method should be considered.

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 4 Feb 1998 19:00:16 -0800

I am speaking about our specific installation of Checkpoint Firewall-1,
from which Cisco and a number of other vendors have licensed technology.
It is as easy to open up a TCP pipe as it is UDP. This is of course a
mechanical method. If you are talking about policy rather than how
difficult it is to actually enable UDP or TCP, then that is a different
story. Most firewall packages I'm aware of assume a certain semantic
content based upon protocol (UDP or TCP) and the associated port number.
The semantic assumptions regarding content usually stem from the
"services" and "well-known-port" documents maintained by IANA, as well
as some industry-wide de-facto standards for TCP/UDP port numbers. 

I know that a number of companies participate in IP Multicast based
services and these types of applications use UDP for delivery of
content. There are other organizations that allow SNMP management
through firewalls through firewall-vendor specific authentication
techniques, as well as source IP address filtering (excepting any IP
spoofing attempts). 

I'm not an expert hacker, and I also don't subscribe to alt.2600, but
the firewall product we use within our organization is the market
leader, and we securely support UDP datagrams through our firewall.

If there are CERT advisories or other real-world scenarios regarding
break-ins or other misuse of UDP datagrams to thwart security, then I
would like to know about them. These of course would need to be detailed
explanations, hopefully not of the form "Well, I've heard UDP is a
problem with firewall admins..."

Randy

	-----Original Message-----
	From:	Larry Masinter [SMTP:[email-masked]]
	Sent:	Wednesday, February 04, 1998 6:20 PM
	To:	Turner, Randy
	Cc:	[email-masked]'
	Subject:	Re: IPP> Notifications

	> UDP has no more firewall or proxy problem than TCP, given any
arbitrary
	> port number.
	> The issues are the same for both. 

	Is this a "first principles" argument? That is, are you speaking
from experience
	with firewall developers and maintainers, or is it just based on
reasoning
	about the nature of the protocols? What I have heard, both from
	local firewall maintainers at Xerox and more generally in
discussions of
	firewall issues in other Internet protocols, is that there's
	a substantial difference in the considerations of a site
allowing
	inbound UDP packets, allowing TCP connections with known
semantic
	content, and allowing inbound HTTP posts with well known data
content.

	Perhaps you have some different data that you could share with
us?

	Larry

---

From: Carl Kugler <[email-masked]>
Date: Thu, 5 Feb 1998 11:11:09 -0500

But... Proxies don't open up TCP or UDP pipes.  Proxies pass nothing through.
Everything gets pulled up to the application level and then resent.  Much more
secure that way.

Also, note that very few corporate firewalls are configured to let NFS
through.  That's partly because NFS is UDP-based and can't be securely
controlled.

 -Carl

[email-masked] on 02/04/98 08:17:53 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet
Subject: RE: IPP> Notifications

I am speaking about our specific installation of Checkpoint Firewall-1,
from which Cisco and a number of other vendors have licensed technology

---

From: Carl Kugler <[email-masked]>
Date: Thu, 5 Feb 1998 11:40:30 -0500

> What will actually happen is that we will all poll :-(

I think that's the best we can do if we limit ourselves to the existing Web
infrastructure.  Meanwhile, implementers will find ways to do asynchronous
notifications outside the IPP box, as proprietary extensions.  Later, the IPP
v2 working group can look at what works and select or synthesize some approach
as standard for IPP asynch notification.  And by then maybe the Web won't be so
asymmetrical.

Anyway, polling might not be elegant, but I think it can do the job.  With
HTTP/1.1, the client will be polling over a persistant connection, so the
overhead should be low.  Polling rates could be fairly slow, since there's no
need for instantaneous notification with an application like printing.

 -Carl

[email-masked] on 02/04/98 01:53:15 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet, Carl Kugler/Boulder/IBM@ibmus
cc:
Subject: RE: IPP> Notifications

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 5 Feb 1998 09:09:32 -0800

I'm not sure what "proxy" means in this context. I'm assuming for the
purposes of realtime asynchronous notification that we would not be
using HTTP as a transport, so any issues surrounding HTTP proxies would
be moot. Are we talking about some other type of proxy?

In my experience, UDP wasn't the problem with NFS mounts over the
internet. Rather, its just too easy to hack NFS UID-style
authentication.  Especially with SUNOS systems that had the annoying
habit of including a "nobody" user UID in the default /etc/passwd file.
This "well-known" UID pair  was used by hackers to mount attacks on the
"/" root partition, retrieving a sites /etc/passwd file, and then
locally running "crack" on their system until they had the root
password. This problem was exascerbated because administrators were too
lazy configuring their "exports" file by including the "/" partition,
and not restricting mounts to this partition to specific hosts only.

Also, NFS these days uses TCP as well, for both NFSv2 and NFSv3, at
least on Sun SunOS/Solaris systems.

Randy

	-----Original Message-----
	From:	Carl Kugler [SMTP:[email-masked]]
	Sent:	Thursday, February 05, 1998 8:11 AM
	To:	[email-masked]
	Subject:	RE: IPP> Notifications

	But... Proxies don't open up TCP or UDP pipes.  Proxies pass
nothing through.
	Everything gets pulled up to the application level and then
resent.  Much more
	secure that way.

	Also, note that very few corporate firewalls are configured to
let NFS
	through.  That's partly because NFS is UDP-based and can't be
securely
	controlled.

	 -Carl

	I am speaking about our specific installation of Checkpoint
Firewall-1,
	from which Cisco and a number of other vendors have licensed
technology

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 5 Feb 1998 11:31:14 -0800

Of course polling is the "standard" solution for status notification in
IPP v1.0. Per our last meeting, IPP v1.0 is "in the bag". We're done. It
was my impression that the entire discussion on async notifications was
within the context of what we need for v2.0.

Randy

	-----Original Message-----
	From:	Roger K Debry [SMTP:[email-masked]]
	Sent:	Thursday, February 05, 1998 10:04 AM
	To:	[email-masked]
	Subject:	RE: IPP> Notifications

	> What will actually happen is that we will all poll :-(

	I think that's the best we can do if we limit ourselves to the
existing Web
	infrastructure.  Meanwhile, implementers will find ways to do
asynchronous
	notifications outside the IPP box, as proprietary extensions.
Later, the IPP
	v2 working group can look at what works and select or synthesize
some approach
	as standard for IPP asynch notification.  And by then maybe the
Web won't be so
	asymmetrical.

	Anyway, polling might not be elegant, but I think it can do the
job.  With
	HTTP/1.1, the client will be polling over a persistant
connection,

	<RKD> So you assume that we would keep a connection open until
	<RKD> a print job is completed and a notification provided? I
	<RKD> don't know if I'd agree that this is a good idea.

	so the
	overhead should be low.  Polling rates could be fairly slow,
since there's no
	need for instantaneous notification with an application like
printing.

	 -Carl

no better in
due to the
cannot send

---

From: Carl Kugler <[email-masked]>
Date: Thu, 5 Feb 1998 15:48:34 -0500

Randy-

By "proxy", I mean "proxy server", specifically "application-level proxy
server" or "gateway":  a server that receives requests intended for another
server and that acts on the client's behalf (as the client's proxy) to obtain
the requested service.  These are high-end firewall devices that operate at the
upper levels of the protocol stack (i.e., all the way up to the application
layer), providing the highest level of protection available today.  The proxy
server changes the IP address of the client packets to essentially hide the
internal client to the Internet, then it acts as a proxy agent for the client
on the Internet. In some cases (e.g., SGI Guantlet), a proxy server is required
for each protocol on a gateway. For example, one is required for HTTP requests,
another for FTP requests, and so on.  Circuit-level gateways (e.g., SOCKS,
rfc1928)  provide a controlled network connection between internal and external
systems.  A virtual "circuit" exists between the internal client and the proxy
server. Internet requests go through this circuit to the proxy server, and the
proxy server delivers those requests to the Internet after changing the IP
address. External users only see the IP address of the proxy server. Responses
are then received by the proxy server and sent back through the circuit to the
client. While traffic is allowed through, external systems never see the
internal systems.   In general the only packets allowed back through a proxy
server are those that return responses to requests from inside the firewall.

I think the type of firewall you're discussing is the router based packet
filtering type (screening router), which works in the lower layers of the
network protocol stack.  It would be interesting to know the install base of
the various types of firewalls.  I know here at IBM we use proxy servers (now
mostly SOCKS gateways, formerly mostly application proxies).

If use a protocol other than HTTP as a transport for realtime asynchronous
notification, won't we lose the advantages that we gained by chosing HTTP in
the first place?

 -Carl

[email-masked] on 02/05/98 10:44:30 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc:
Subject: RE: IPP> Notifications

Randy

 -----Original Message-----
 From: Carl Kugler [SMTP:[email-masked]]
 Sent: Thursday, February 05, 1998 8:11 AM
 To: [email-masked]
 Subject: RE: IPP> Notifications

  -Carl

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 5 Feb 1998 14:16:18 -0800

The proxy you are talking about is SOCKS-based...ok, I understand how
SOCKS works. That's pretty much all we had until real firewall products
came along, and yes SOCKS-based products might have a problem with UDP.
But I don't think the majority of enterprise firewall solutions are
based on SOCKS, because it is doesn't quite have the flexibility of real
firewall products. SOCKS application gateways require that all
applications be modified to speak SOCKS, and if not the applications,
then the runtime libraries or DLLS or whatever have to modified.
Products like Checkpoint Firewall-1 and other firewall products are much
more transparent with regards to their NAT (network address translation)
capabilities. In my opinion, SOCKS is more of a niche player in the
enterprise firewall world. But this is just my opinion.

I also don't think we are losing anything by defining a notification
method outside of HTTP; in fact, we could define a standards-track
document for IPP async notifications that would be immune to legacy or
other future protocol mapping techniques for IPP job submission. Like
Paul Moore mentioned in an earlier mail message, HTTP wasn't designed
for this type of functionality (async notifications)  so I think a
separate out-of-band (to HTTP) method is in order. 

Randy

	-----Original Message-----
	From:	Carl Kugler [SMTP:[email-masked]]
	Sent:	Thursday, February 05, 1998 12:49 PM
	To:	[email-masked]
	Subject:	RE: IPP> Notifications

	Randy-

	By "proxy", I mean "proxy server", specifically
"application-level proxy
	server" or "gateway":  a server that receives requests intended
for another
	server and that acts on the client's behalf (as the client's
proxy) to obtain
	the requested service.  These are high-end firewall devices that
operate at the
	upper levels of the protocol stack (i.e., all the way up to the
application
	layer), providing the highest level of protection available
today.  The proxy
	server changes the IP address of the client packets to
essentially hide the
	internal client to the Internet, then it acts as a proxy agent
for the client
	on the Internet. In some cases (e.g., SGI Guantlet), a proxy
server is required
	for each protocol on a gateway. For example, one is required for
HTTP requests,
	another for FTP requests, and so on.  Circuit-level gateways
(e.g., SOCKS,
	rfc1928)  provide a controlled network connection between
internal and external
	systems.  A virtual "circuit" exists between the internal client
and the proxy
	server. Internet requests go through this circuit to the proxy
server, and the
	proxy server delivers those requests to the Internet after
changing the IP
	address. External users only see the IP address of the proxy
server. Responses
	are then received by the proxy server and sent back through the
circuit to the
	client. While traffic is allowed through, external systems never
see the
	internal systems.   In general the only packets allowed back
through a proxy
	server are those that return responses to requests from inside
the firewall.

	I think the type of firewall you're discussing is the router
based packet
	filtering type (screening router), which works in the lower
layers of the
	network protocol stack.  It would be interesting to know the
install base of
	the various types of firewalls.  I know here at IBM we use proxy
servers (now
	mostly SOCKS gateways, formerly mostly application proxies).

	If use a protocol other than HTTP as a transport for realtime
asynchronous
	notification, won't we lose the advantages that we gained by
chosing HTTP in
	the first place?

	 -Carl

	I'm not sure what "proxy" means in this context. I'm assuming
for the
	purposes of realtime asynchronous notification that we would not
be
	using HTTP as a transport, so any issues surrounding HTTP
proxies would
	be moot. Are we talking about some other type of proxy?

	In my experience, UDP wasn't the problem with NFS mounts over
the
	internet. Rather, its just too easy to hack NFS UID-style
	authentication.  Especially with SUNOS systems that had the
annoying
	habit of including a "nobody" user UID in the default
/etc/passwd file.
	This "well-known" UID pair  was used by hackers to mount attacks
on the
	"/" root partition, retrieving a sites /etc/passwd file, and
then
	locally running "crack" on their system until they had the root
	password. This problem was exascerbated because administrators
were too
	lazy configuring their "exports" file by including the "/"
partition,
	and not restricting mounts to this partition to specific hosts
only.

	Also, NFS these days uses TCP as well, for both NFSv2 and NFSv3,
at
	least on Sun SunOS/Solaris systems.

	Randy

	 -----Original Message-----
	 From: Carl Kugler [SMTP:[email-masked]]
	 Sent: Thursday, February 05, 1998 8:11 AM
	 To: [email-masked]
	 Subject: RE: IPP> Notifications

	  -Carl

---

From: Carl Kugler <[email-masked]>
Date: Thu, 5 Feb 1998 19:12:58 -0500

Persistent connections are really the domain of the HTTP transport layer, not
IPP.

But anyway, I was thinking of polling intervals of around 30 seconds.  At that
rate, maintaining a connection for the lifetime of the job is probably cheaper
than tearing down and re-establishing a connection for each poll.  HTTP servers
are free to close connections any time, so if the server is running low on
memory it can close idle connections at will.  If the server has the resources
to keep the connection open, then the client shouldn't close it unless the
client will not be using the server again for at least a minute, since closing
and then reopening adds computational overhead to the server, adds round trip
delays, results in more network traffic from overhead (SYN, ACK, FIN) than
payload data, and consumes server resources with closed connections in
TIME_WAIT.

References:

HTTP Connection Management:
ftp://ietf.org/internet-drafts/draft-ietf-http-connection-00.txt

The Case for Persistent-Connection HTTP:
http://www.research.digital.com/wrl/techreports/abstracts/95.4.html

    -Carl

[email-masked] on 02/05/98 01:10:31 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc:
Subject: Re: IPP> Notifications

> HTTP/1.1, the client will be polling over a persistant connection,
>

I agree with Roger.  Maintaining a connection for the lifetime
of the job will not scale very well in large environments.

Maintaining a constant connection might be ok for the "Internet fax
printer" scenario, but it just won't fly in the enterprise.

 ...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------