Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

On Fri, Jun 1, 2012 at 10:15 AM, Kyle Hamilton <aerowolf <at> gmail.com> wrote:
> This is damaging, and I recommend against.  This is something which must be
> handled by HTTP and its demands of its transports, not TLS and its claim to
> support what it thinks its clients want.
>
> Among other things, this RFC more than any other is responsible for the
> "Server Name Indication" requirement.  If it had not been the case, SNI
> would never have been necessary, and IESG/IETF would never have had to deal
> with it.

Huh? As stated in the abstract, RFC 2818 documented what was already
established practice at the time it was published. Yes, that practice
leads directly to SNI, but it's not like it's the fault of 2818.

> I suggest instead that it be moved to HISTORIC, and a 2818bis drafted which
> describes how the various TLS extensions play with HTTP.

I don't understand what that would mean. At the time 2818 was published,
there were already complaints about the HTTPS mechanism (though
primarily directed towards the use of a separate port) and the IETF
took a stab at trying to define a protocol that it liked better (2817).
That was hardly a success. It's hard to believe that we're going to
make fundamental architectural changes now, given that HTTPS
is far more entrenched.

-Ekr