- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 28 Feb 2013 08:59:05 +1100
- To: James M Snell <jasnell@gmail.com>
- Cc: Roberto Peon <grmocg@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Mike Belshe <mike@belshe.com>
To me, a distinct name of a major, separable part of a protocol is only good spec hygiene; in HTTP we already have "representations" (nee "entities"), "resources" and so forth. They allow people to talk about different things that are happening with clarity; right now, people are using the term "HTTP/2.0" very, very sloppily, and that's a concern. "It means what I mean" is not a great basis for communication. I don't think that changing the name will add any more complexity unless we allow it in based upon assumptions that it therefore *has* to be completely separable, and I'm explicitly not bringing that to the table. Cheers, On 28/02/2013, at 5:56 AM, James M Snell <jasnell@gmail.com> wrote: > No one said that subprotocols would not still be possible on top of > the same framing mechanism. Mark's question was about naming only, not > design. There is still a good design separation between the HTTP > semantics and the framing layer, and the framing layer would still be > reusable beyond just carrying http semantics. > > On Wed, Feb 27, 2013 at 10:51 AM, Roberto Peon <grmocg@gmail.com> wrote: >> Then you can't do websockets, etc or whatever other protocol (maybe video?, >> who knows) the web platform decides to do in the future on the same >> socket/session. >> >> That would be a poor tradeoff.. and for what gain? >> What is the additional complexity of having the framing allow for non HTTP >> semantics? >> -=R >> >> >> On Wed, Feb 27, 2013 at 10:13 AM, James M Snell <jasnell@gmail.com> wrote: >>> >>> +1 >>> >>> On Feb 27, 2013 10:03 AM, "Martin Thomson" <martin.thomson@gmail.com> >>> wrote: >>>> >>>> On 27 February 2013 00:49, Mike Belshe <mike@belshe.com> wrote: >>>>> My vote would be to nuke the layering and instead fold section 4 (the >>>>> HTTP >>>>> Layering) into the appropriate sections of the framing layer. Trying >>>>> to >>>>> make these generic frames seems like a distraction, and it would be >>>>> simpler >>>>> for folks to read if these were just the basics of HTTP framing. >>>> >>>> I said as much to mark in private: the framing layer is for HTTP. A >>>> name implies that it might stand alone. That's not going to be true. >>>> The work to make it true is not worthwhile either. >>>> >> -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 27 February 2013 21:59:32 UTC