Subject: IPP> Some observations from the IPP BOF in the IETF

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 16 Dec 1996 19:52:30 PST

Hi,

here follows some of my impressions from last week's BOF meeting:

1) The IETF is becoming more structured and formal in its approach to
making standards. This has both pro's and con's. It will increase the
quality of the standards, but it will also slow down the process
considerably.  Making a complete set of RFCs for IPP in 6 months seems to
be rather futile, following the latest IETF rules.

2) It seems that the IETF Application Area Directors are rather negatively
oriented towards both HTTP and LDAP, things that we planned to include in
our solution. Is this a case of "not invented here" (both originated
outside the IETF), or is it a question of quality control for new standards?

3) On the other hand, the Area Directors and everybody else, seem to be in
love with MIME (even if it means stretching the use of MIME into areas for
which it was not originally designed).  We cannot go wrong if we use MIME.

4) The route to get approval for our IPP project seems to be concentrating
on describing our application specific data (such as operations and
attributes) in MIME format and describe generic use and attributes for
directory services, but to forget about mapping it to HTTP and LDAP for
now.  It was suggested that doing things in sequence would be better than
trying to do mappings to "transports" at the same time.

5) If we were to accept all the proposals made, it seems that our objective
of having working prototypes out within 6 months are doomed.  However, we
have several alternatives on how to proceed.  We could accept the reduced
scope from IETF, but could keep up the work on the other subjects in the
PWG, for later introduction in the IETF.  Or we could consider getting the
W3C organization interested in working on the HTTP mapping.  We could also
consider the proposal to design a new dedicated protocol to run directly on
top of TCP (which would take us out of the discussion about whether HTTP is
good or bad).  Let us try to get quick agreements on which way to go, so
that we do not slow down the progress of our project in particular in our
prototype teams.

6) We had 80 people attending our BOF session and I counted about 2/3 of
those being actively interested in getting IPP off the ground.  Whatever we
do, we should not let the IETF bureaucracy slow us down in doing real work.

7) Our concept of using HTTP to avoid Firewalls seem to be flawed.  I spoke
to several security specialists about it and they called us naive. They
pointed out that any firewall provider worth its salt would use IPP as a
good excuse to sell their customers a new version of their firewall -
whichever way we do it.

my 2 cents...

Carl-Uno

---

From: Babak Jahromi <[email-masked]>
Date: Mon, 16 Dec 1996 20:06:34 -0800

>good excuse to sell their customers a new version of their firewall -
Carl,

Could you be more specific here? If we stick to the basic HTTP, how can
the firewall provider tell what the HTTP command really transporting?
And how can they convince their customers that they need a new firewall
that works better by poking into the HTTP commands to search for IPP
stuff?

Thanks,
Babak

---

From: Carl-Uno Manros <[email-masked]>
Date: Mon, 16 Dec 1996 23:06:35 -0800

>that works better by poking into the HTTP commands to search for IPP

Babak,

The main argument given to me was that a number of security concious
organizations are prohibiting the delivery of data out from their
organization e.g. via FTP, while allowing HTTP on the basis that it is
normally used to get data in from the outside, but gives out very little
data.  If we start using IPP to send out big print files, these
organizations will start getting worried and looking for a stopgap solution,
until they find a way to dig into the HTTP flow for details. A short term
solution might be to quite simply have the firewall stop the use of HTTP
altogether.

Carl-Uno

---

From: Don Wright <[email-masked]>
Date: 17 Dec 96 8:04:02 EST

>From my perspective, the intent for using HTTP is that
is that if nothing is changed in the firewall, printing would
work.  If some paranoid companies want to prevent
printing to printers outside the company (I assume these
same companies have disabled all the scanners in
their fax machines, turned off outgoing e-mail and 
no longer allow outbound snail mail in opaque envelopes)
then they can get new firewall software or turn off HTTP
completely.  That is their policy decision.  For the rest of
us, we don't have to worry about getting a firewall update, 
loading new client software on thousands of machines, 
etc.  The intent is to make adding Internet printing support
easy for those that want it.

DON

To: babakj%MICROSOFT.com @ interlock.lexmark.com (Babak Jahromi) @ SMTP, 
cmanros%cp10.es.xerox.com @ interlock.lexmark.com ("'Carl-Uno Manros'") @ SMTP
cc: ipp%pwg.org @ interlock.lexmark.com ("[email-masked]'") @ SMTP (bcc: Don 
Wright)
From: manros%mindspring.com @ interlock.lexmark.com (Carl-Uno Manros) @ SMTP
Date: 12/16/96 11:06:35 PM
Subject: RE: IPP> Some observations from the IPP BOF in the IETF

Babak,

Carl-Uno