[BXXPwg] SOAP over BEEP
Sat, 16 Jun 2001 09:14:35 -0700
Roy, I think you make great points that a) the URL scheme can signify
more than just secure or not (such as caching)) and that b) it's
essential that the client not reveal more information than necessary by
during the security negotiation.
However, my read of RFC 3080 is that it is possible for the BEEP peer to
provide a tuning profile that ONLY indicates upgrading to TLS (or
whatever, including intricate combinations of transport and SASL
profiles), and fails to return anything else. See, for example, the
long example at the beginning of section 3.
In that case, no cleartext data communication is made. Phrased
differently, the first resource request -- if it is a request for a
secure channel -- is always tuned in the clear, and so a single URL
scheme should suffice.
Dan Kohn <mailto:email@example.com>
From: Roy T. Fielding [mailto:firstname.lastname@example.org]
Sent: Friday, June 15, 2001 20:53
To: Dan Kohn
Subject: Re: [BXXPwg] SOAP over BEEP
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
> they carry, and transport layers they run over (including port
> 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
> that every new protocol issued did not need 2 port numbers, one for
> 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
> 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
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.