> IPP clients should use "https:", without overriding the port #,
> to indicate they want to talk to an IPP server on port 443.
I'm a little confused about what it means for an IPP client to "overrid=
e the
port #". The port is what the client connects to, but as far as I know=
the
number isn't passed in the HTTP or IPP protocols, right? The client has=
to
connect to some port; should it be 443 or 80 in this case?
-Carl Kugler
ipp-owner at pwg.org
01/07/98 12:03 PM
Please respond to ipp-owner at pwg.org @ internet
To: cmanros at cp10.es.xerox.com @ internet
cc: ipp at pwg.org @ internet, moore at cs.utk.edu @ internet,
Harald.T.Alvestrand at uninett.no @ internet, ietf-tls at consensus.com @ int=
ernet
Subject: IPP> Re: URI scheme and port numbers for TLS
> Is it assumed that each application that uses TLS uses its own origin=
al
> scheme e.g. "http" or should it allocate a new scheme if combined wit=
h TLS
> (Annex E seems to suggest that you use "https" as for SSL3)?
Ideally, a single URL scheme could be used either with or without TLS,
with the authentication and privacy technology to be used negotiated
by the client and server. Client and server should each be
configurable as to which ciphersuites, CAs, etc. are acceptable to
each party.
In general, neither the scheme name, nor the port number, is
sufficient for such configuration. For instance, "https" (and port
443) can be used with many different ciphersuites, covering a wide
variety of services and strengths, some of which are unlikely to be
acceptable. While we don't intend to deprecate https/http and the
other dual-port schemes that are widely deployed, neither do we want
to propagate this mechanism to new protocols.
> Do you see any reasons to allocate new schemes and/or port numbers fo=
r IPP
> (differently from HTTP) when using HTTP as transport? If you think ne=
w
> schemes and ports are needed, do we need one for use of IPP without T=
LS,
> and another set for use with TLS?
IANA has been requested to not assign any new "SSL" or "TLS" ports.
For new protocols, TLS must either to be explicitly configured
separately from the port number, negotiated in-band (using STARTTLS or
some such), or assumed by default.
As for IPP:
+ IPP servers listening on port 443 should assume TLS/SSL will
be used when the connection is opened.
IPP clients should use "https:", without overriding the port #,
to indicate they want to talk to an IPP server on port 443.
+ IPP servers listening on other ports, including any port that might
be designated specifically for IPP, should assume that neither TLS
nor SSL is used when the connection is established. TLS or other
security technologies might eventually be used on such servers,
if someone defines a means of negotiating security in-band over
HTTP.
IPP clients should specify "http:", perhaps with a port #
(other than 443), to indicate that they want to talk to such servers.=
+ If a specific port is to be allocated for IPP, there should be
an "ipp:" URL scheme defined, which defaults to that port.
The definition of the ipp: scheme should also define how security
is to be negotiated on that port - whether it defaults to TLS
(perhaps with the possibility of fallback to a null encryption
layer) or whether it uses in-band negotiation.
In every case it remains necessary for clients and servers to be
configurable as to which TLS ciphersuites are acceptable.
Keith
=