> From carl at manros.com Fri Sep 12 16:34:47 1997
> Date: Tue, 09 Sep 1997 19:39:52 -0700
> To: Peter Zehler <pzehler at channels.mc.xerox.com>, ipp at pwg.org> From: Carl-Uno Manros <carl at manros.com>
> Subject: Re: IPP> TES Meeting Minutes
>> At 12:36 PM 9/9/97 PDT, you wrote:
>>.....
> >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?
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.)
>> >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.
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.
>> > 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.
>
Again, it may be appropropriate to discuss this under the 'security' issues.
> > 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
>
Patrick Powell Astart Technologies,
papowell at astart.com 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)