Re: Section on https

> We nuked this due to under-cookedness.  I'm sympathetic to Ian's 
> point, so I've shaken & stirred the existing language slightly; I 
> understand the date is very late, but if lots of TAG members write 
> back and say "yes" maybe it could squeeze in:

I didn't like it because it is just wrong.  Security policy can only be
negotiated if you decide to manage it prior to making a request, which 
is
obviously a bad idea for a protocol that does not require security
99.999% of the time.  It is therefore a better trade-off to separate
the need-to-negotiate services from those that don't need it, and the
only way to do that is by indicating the separation within the URI
because the client needs to know *before* the first request.  The
next question is then whether we want these services on the same
port as the unsecured protocol, and the answer is generally "no" since
that interferes with the ability to pipe-filter servers.  Finally,
would we want the same services to be available via both http and
https?  An emphatic "no" to that one, since it results in security
holes.  We could argue that the "s" bit doesn't belong in the scheme,
but since it defines a separate resource space the result would be
equivalent to a separate scheme regardless of where it appears in
the URI.

As a result, the "https" scheme or something equivalent to it is and
will always be necessary, and the resources identified by it have no
connection whatsoever to the resources identified by the "http" scheme
even if you have two URI that only differ in the "s".

Thus, the example is incorrect.

....Roy

Received on Thursday, 4 December 2003 15:14:41 UTC