> Is it assumed that each application that uses TLS uses its own original
> scheme e.g. "http" or should it allocate a new scheme if combined with 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 for IPP
> (differently from HTTP) when using HTTP as transport? If you think new
> schemes and ports are needed, do we need one for use of IPP without TLS,
> 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