Roy T. Fielding fielding@ebuilt.com
Thu, 28 Jun 2001 14:44:29 -0700

On Thu, Jun 28, 2001 at 10:11:13AM -0700, Darren New wrote:
> Not really. If the server only advertises TLS in the greeting upon
> connection, it's pretty obvious to the client that that must be
> negotiated first.

The problem I was referring to is one where you have

                                     .------------> service peer
    client peer <=======> proxy peer -------------> service peer
                                     `------------> secure service peer

wherein the client has a semi-permanent beep session with the proxy,
which in turn accesses many different services.  Because the profile
is selected on a per-connection basis and negotiated up-front, the
proxy doesn't find out that the third service peer requires security until
after the client peer has sent a request in the clear to the proxy.  The
ways to avoid the problem are to require that beep proxy connections
always be secure (not really practical), or require that an indicator
of the secure connection requirement be supplied with the identifier,
so that the client peer can know in advance that it must create a
separate, secure connection to the proxy for that request.  That is
why the Web needed both http and https naming schemes.

Note that this problem depends on the nature of the application
architecture, but will certainly apply to soap over beep.