> - While the conference call was still open, we discussed the
> use of a port besides 80. It was the consensus that we
> would not mandate an alternative port number but we would
> not preclude some implementations from using alternative
> ports. The protocol document should make a statement that
> by default IPP should be supported by servers and clients
> over port 80.
I think that this is a serious mistake. What is happening here is you
are adding required functionality to a HTTP port service without
coordinating this with the folks doing the HTTP stuff.
In addition, you are requiring non-printer vendors to supply
a HTTP server that will not only do regular HTTP functionality
but also provide support for IPP as well if they want to do GATEWAY
support for the IPP protocol to other print systems.
This is the part where I disagree strongly.
If you have a separate port for IPP, then the IPP server and the HTTP
server can be separate; if you (and ALL HTTP server implementations
that I have looked at support this) support an 'alternate' port
or range of ports, then this can be easily supported. Note: it is
common to use port 8080 for 'test' purposes in many HTTP servers,
and to allow 'CGI' type of applications to 'check' on the type
of connection allowed. This has to do with firewalls, and internal
versus external connections, where only INTERNAL hosts can access
via port 8080 and EXTERNAL hosts cannot.
If the IPP protocol is only going to be implemented for NON-GATEWAY
type applications, i.e. - where you are NOT going to add IPP functionality
to a host for system managment purposes, then I think this would
be supportable. But since there is constant and concerning discussion
about Gateways, and the problems of Gateways, then we MUST make gateways
as simple and trivial to implement, independent of the HTTP server.
So the argument about needing all HTTP or similar protocols to go to port 80
(i.e. - HTTP server is misleading) if not downright fallacious.
I apologize for such strong language, but I feel that this statement
must be made.
Patrick Powell
PHILOSOPHICAL STATEMENT
I think that one of the things to keep in mind is separation of functionality
in the TCP/IP world was/is done by PORT number, NOT overloading a
protocol and server with new/different required functionality.
Example: SSH and RSERVICES use different ports - even though it is
possible to have the RSERVICES server (rlogin, etc.) distinguish
between the type of protocol.
In fact, pushing this to an extreme, you could even have FTP/SNMP
on the same port, and have the functionality distinguished by the
initial connection conversation.
The TCP/IP design was based on using port numbers to distinguish the
type of service, even if the 'application protocol level' was different.
I think that you will encounter a great deal of opposition if you try
to push this through.