Roy T. Fielding fielding@ebuilt.com
Fri, 15 Jun 2001 20:52:33 -0700

On Fri, Jun 15, 2001 at 06:52:55PM -0700, Dan Kohn wrote:
> There is an imprecise and not fully defined mapping between
> application-level protocols, profiles those applications use, MIME types
> they carry, and transport layers they run over (including port number).
> One important data point on the design of HTTP URLs is RFC 2817
> <http://www.normos.org/ietf/rfc/rfc2817.txt>, which the IESG demanded so
> that every new protocol issued did not need 2 port numbers, one for over
> TCP and one for over TLS.
> In that sense, the https URL specification
> <http://www.normos.org/ietf/rfc/rfc2818.txt> was grandfathered in but is
> not a good model going forward.

That is not sufficient.  The client must know whether or not the
connection must be secured before it makes the first resource request of
the server.  In order to know that, the information must be in the URI.
The mechanism used to establish the secure session might be present
in the protocol, as it is with HTTP/1.1 Upgrade, but the decision to make
that upgrade mandatory prior to sending any sensitive information is
something that the client must make using only the URI as a guide.

The IESG objected to multiple TCP ports per protocol, not multiple
scheme names.  There is no reason why a new "s" scheme cannot be defined
with the same default port as the normal scheme, just as there is no
reason why https services cannot be located on port 80.  The client,
however, still needs the distinct schemes in order to know how it
should contact the server.  https, in particular, not only requires
that contact with the naming authority be secure, it also requires that
all application hops along the way to the naming authority be secure,
and further that nothing on that chain be cachable by default.  https
therefore defines much more than simply HTTP over SSL.