Subject: Re: IPP> TES Meeting Minutes

From: Carl-Uno Manros <[email-masked]>
Date: Tue, 09 Sep 1997 19:39:52 -0700

At 12:36 PM 9/9/97 PDT, you wrote:

>We also discussed what is required to move from an Internet Draft to a
>Proposed Standard.  It is my understanding that we need 2 interoperable
>implementations.  This would mean 2 clients and 2 IPP Printers that
>interoperate with each other.  The implementations should be on a
>product tract.  This is the part that is not very clear.  Hopefully the
>area director will make the requirements explicit for moving from
>Internet Draft to Proposed Standard.  I expect the area director to
>specify what proof of interoperability must be supplied.

This is a misunderstanding.  It is not until we want to move the documents 
from Proposed to Draft standards that we actually have to give proof of
interworking implementations.  Our ambition was to have this already before
the Proposed Standard was published, but that is not a requirement to get
it out.  So we can relax a little on that point, which however should not 
be a reason to get on with the prototyping..

>It was suggested that a TCP port be allocated for IPP(516 was
>suggested).  Some of us use 3rd party embedded HTTP servers.  We need to
>find out from these companies is supporting IPP on a port other than
>port 80 is a problem.  Ira will check with SpyGlass and I will see if I
>can get input from other vendors.  This issue will be brought to the
>full IPP group.

We have discussed this earlier and came to the conclusion that there was
no obvious advantage in having a separate port as part of the standard.
Do we have any new compelling arguments now?

>We discussed pairwise and blanket IPP interop testing.  An IPP Bakeoff
>would have to be arranged to handle the blanket test.  We are not ready
>for this at this time.  (How much lead time will we need to prepare?)
>Pairwise testing seem to be a sticky point.
>   1)  Can an implementer place his IPP Printer on the public side of
>their firewall?

We are prepared to do this.

>   2)  Are we worried about security issues for initial tests?

Suggest that we can start without worrying too much about security,
as long as we only gove our Printer URIs to other vselected testers.

>   3)  Would a proxy server using SSL or TLS help security?

It probably would, but this seems to be more work than putting a printer
outside the firewall initially.

>   4)  Can we work with a firewall vendor to prototype modifications
>necessary for IPP support?

Let us see if we can find one.

>   5)  Would a publicly available IPP client make the across the
>Internet pairwise testing unnecessary?
>The way it stands right now is that any two individuals are encouraged
>to arrange a pairwise test.  Groupwide IPP pairwise testing is not ruled
>out.  We still have obstacles in the way.
>
>There are two main roadblocks to the IPP TES group.  One is the IPP
>JobId/JobURI issue.  The next is the security issue.  These issues will
>be passed on to the IPP chair.

You are right, that we definately need to settle on the JOB URI decision 
quickly.  The same goes for security, but I think we can do quite a lot of 
testing also without security at this stage.

Carl-Uno

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Wed, 10 Sep 1997 12:27:14 PDT

Hi Carl-Uno and IPP folks,                      Wednesday (10 Sept 1997)

Carl-Uno, you are right that interoperable implementations are not
REQUIRED for publication as an IETF 'Proposed Standard'.  Nonetheless,
interoperable implementations are RECOMMENDED (see the excerpt below),
and are common practice in protocols submitted as 'Proposed Standards'
for intermediate systems (routers, hubs, bridges, etc).

Cheers,
- Ira McDonald (outside consultant at Xerox)
  906-494-2434

>From IETF 'Internet Official Protocol Standards' (RFC 2200, June 1997),
page 8:

   4.1.2.  Draft Standard Protocol

      The IESG is actively considering this protocol as a possible
>>    Standard Protocol.  Substantial and widespread testing and comment
>>    are desired.  Comments and test results should be submitted to the
>>    IESG.  There is a possibility that changes will be made in a Draft
      Standard Protocol before it becomes a Standard Protocol.

   4.1.3.  Proposed Standard Protocol

      These are protocol proposals that may be considered by the IESG
>>    for standardization in the future.  Implementation and testing by
>>    several groups is desirable.  Revision of the protocol
      specification is likely.

---

From: [email-masked]
Date: Mon, 15 Sep 1997 18:09:12 -0700 (PDT)

> From [email-masked] Fri Sep 12 16:34:47 1997
> Date: Tue, 09 Sep 1997 19:39:52 -0700
> To: Peter Zehler <[email-masked]>, [email-masked]
> From: Carl-Uno Manros <[email-masked]>
> Subject: Re: IPP> TES Meeting Minutes
>
>.....

    It allows the separation of the use of the IPP protocol from that of
    HTTP default connection port.  If you want to implement separate IPP
    servers, then you have the option of doing this.

    If in the future,  the protocol on PortXXX (HTTP) is ever changed, then
    the protocol on Port UUU for "IPP" will not change.

    The separate port allows "firewalls" to separate different types of
    traffic on a functional basis.  I think that expecting a HTTP server to
    perform all of the actions of a Print Server is overloading the protocol
    and functionality just a little.  (For completeness,  I must note that
    I consider the overloading of HTTP for downloading files to the HTTP server
    a terrible mistake as well.)

> as long as we only gove our Printer URIs to other vselected testers.

I note that by having a separate port, you can filter the connections
and restrict them from other sites in a trivial manner.  This is another
advantage of the separate port - a 'defense in depth' type of approach.

> outside the firewall initially.

Again, it may be appropropriate to discuss this under the 'security' issues.

> testing also without security at this stage.

Patrick Powell                 Astart Technologies,
[email-masked]            9475 Chesapeake Drive, Suite D,
Network and System             San Diego, CA 92123
  Consulting                   619-874-6543 FAX 619-279-8424 
LPRng - Print Spooler (http:www.astart.com/LPRng)