Subject: RE: IPP> review of IPP documents

From: Paul Moore <[email-masked]>
Date: Fri, 29 May 1998 17:41:07 -0700

You miss the point - I agree totally about the penetration issue. I think
this is a bad reason for doing anything.

The proxy issue is quite different - the most common scenario in commercial
networks is that the users are not connected to the Internet at all (hence
firewalls dont enter the debate). Proxies enable these users to access
internet resources. (this is not a terminology issue - they are
fundamentally differnt things). By making IPP use http:80 then IPP printer
become another Internet resource accessible via my proxy.

Punching a hole in the firewall is missing the point - they can do whatever
they like to the firewall - it does not change what I can access from my
desktop. My PC can only reach those things that my proxy knows how to deal
with. If I took the proxy away I could not reach anything. This is the
inverse case from the case where my desktop is connected to the internet via
a firewall - I you take the firewall out of the loop I would be able to do
anything.

I cannot ping your machine from my desktop, this has nothing to do with the
MS firewall settings.

> -----Original Message-----
> From:	Keith Moore [SMTP:[email-masked]]
> Sent:	Friday, May 29, 1998 5:31 PM
> To:	Paul Moore
> Cc:	'Keith Moore'; [email-masked]; [email-masked]
> Subject:	Re: IPP> review of IPP documents 
> 
> > Typically (take MS for example). The firewall and the proxy are quite
> > differnt things. The proxy is an enabler and the firewall is a
> protector.
> 
> okay...slightly different use of terminology.
> 
> insisting on IPP using port 80 just to be able to tunnel through 
> firewalls/proxies simply will not fly ...it leads to an arms race.
> (not to mention that everybody will want to use port 80, which 
> is clearly unworkable)
> 
> if your employer wants you to be able to use external printers,
> they can punch a hole in their firewall, or add a proxy, to 
> allow you to talk to the default IPP port. 
> 
> we can't let the existence of NAT boxes dictate the whole architecture.
> 
> Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 May 1998 20:52:20 -0400

You miss the point.  The fact that people already have port 80 proxies
installed doesn't matter.  There's no way that we're going to standardize
IPP on port 80 - HTTP already has that port, and IPP is a different
service than HTTP.

Once upon a time, a lot of people had email only access to the Internet.
That wasn't an good reason for forcing every service to run over email.

Keith

---

From: Ned Freed <[email-masked]>
Date: Fri, 29 May 1998 18:49:12 -0700 (PDT)

> That wasn't an good reason for forcing every service to run over email.

My favorite example is email over FTP. We'd still be doing email that way
if we hadn't deployed a new email service on a separate port.

				Ned

---

From: "Carl Kugler" <[email-masked]>
Date: 2 Jun 1998 16:58:20 -0000

> if we hadn't deployed a new email service on a separate port.
I think an important goal in distributed application design is to MINIMIZE the number of application-specific protocols required.  Ideally, the designers of SMTP would have looked beyond the immediate problem of email, and devised a generic, extensible application protocol that not only met the needs of FTP and email, but would have enabled an unlimited number of additional applications.  Isn't that what people are trying to do today with XML?  TCP does this very successfully at its level in the stack.

I think it's a waste to have to modify the infrastructure each time you want to support a new distributed application.  That's like having to upgrade your computer's operating system every time you want to install a new application:  something that should be minimized.  

Carl Kugler

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 4 Jun 1998 12:18:10 PDT

>if we hadn't deployed a new email service on a separate port.

Ned,

If this is your favorite example, why have I not heard you arguing that
IFAX cannot be done over SMTP?

Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Ned Freed <[email-masked]>
Date: Thu, 04 Jun 1998 15:07:01 -0700 (PDT)

> IFAX cannot be done over SMTP?

Well, first of all, because one doesn't follow from the other. I never said it
is impossible to do email over FTP -- the fact of the matter is that it was
possible to do it, and had we continued in that vein I see no overwhelming
obstacle to doing it this way today.

Similarly, it is possible to do IPP over HTTP. Or SMTP. Or FTP. Or even TELNET.
And IFAX can be done over SMTP. Or HTTP. Or FTP. Or even TELNET. So I certainly
would not argue that any of these are impossible, since that simply is not the
case.

Now, I suspect you intended to say was:

  If this is your favorite example, why have I not heard you arguing that
  IFAX should not be done over SMTP?

And the answer to this is simply that if you have not heard me arguing this you
must not have been listening. I have pointed out, not once but many times, that
if the service characteristics needed by a new IFAX service are intrinsicly
different from those of an email service then the only available option is to
build IFAX as a separate and cleanly dilineated service. There is no way to
achieve interoperability otherwise, and interoperability is something the IETF
requires.

However, I have also pointed out that the cost of building a new store and
forward service is high, far higher than the cost of simpler point-to-point
services, and that this cost has to be weighed against benefits of that new
service.

I am largely neutral on which way the IFAX work goes on this point. My major
concern has been that if IFAX is to be defined as a profile of email and not as
a new service, that it approach this layering realistically and carefully, so
as not to break existing services or damage the service models already in
place.

				Ned

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 4 Jun 1998 16:05:12 PDT

Ned,

What I really meant with my comment, is that the IETF is not very
consistent and clear in what a tranport layers vs. an application layer is,
and keeps on mixing the two in a pragmatic, but architectually unsound and
ad hoc way.
Is the Internet Architecture Board ever paying any attention to these kind
of discussions?

Carl-Uno

Carl-Uno Manros