- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Tue, 13 Nov 2012 11:26:55 -0500
- To: Eliot Lear <lear@cisco.com>
- Cc: James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <CAMm+Lwh9mjw98C-CmU_TqYJDHEaE_7fLLpeU=q89ky34YKaOww@mail.gmail.com>
I would say that the requirement for the DNS option for signalling upgrade be that 1) It be an instance of a general mechanism that can be used to signal more than just protocol version and more than just information to HTTP. 2) It be possible to secure the protocol version information to prevent downgrade attacks, and upgrade attacks. In band upgrade hacks are a one-off solution. Complexity is frequently the result of too many one-off solutions. We do occasionally have complexity from systems that are too general (ISAKMP, EAP, GSSAPI). But that comes from schemes that are designed to allow people to achieve the same basic function in an infinite variety of ways. I can't think of a case where we have introduced too much complexity by specifying one 'right' way to implement a function plus one or two fallback mechanisms to work-around legacy issues. There are also advantages to defining a DNS mechanism that are not quite requirements. One of them being that HTTP/1.1 use of DNS is rather a mess and this provides an opportunity to clean it up. In particular, HTTP relies on DNS server hacks to implement load balancing (the round robin hack). SRV is a better solution for Web, URI is a better solution for Web Services. But neither SRV nor URI are complete in that respect as neither addresses geographic load balancing. I do not want to get into the issue of how to implement those features right here and now. But I would like us to take an approach to getting out of the HTTP version swamp that provides us with the necessary hooks to get out of the load balancing, geography etc. swamps in the future. HTTP/2.0 is an incompatible upgrade. When you break backwards compatibility you should always have (1) a very good reason to do so and (2) an explanation for why you do not expect to do so again. On Tue, Nov 13, 2012 at 11:07 AM, Eliot Lear <lear@cisco.com> wrote: > James, > > The question I asked isn't whether or not to use DNS, but what the > requirements for a record would be. From Phil I gather that limited > complexity is a goal (we will of course argue what that means). What > are your goals for a DNS record? > > Eliot > > -- Website: http://hallambaker.com/
Received on Tuesday, 13 November 2012 16:27:36 UTC