4 ms·

> That's a feature, not a bug. No, it's definitely a bug. You can have extensiblity without ambiguity, see the examples below... > Name a binary application l

by magila 11y ago

> That's a feature, not a bug. No, it's definitely a bug. You can have extensiblity without ambiguity, see the examples below... > Name a binary application level protocol that has achieved adoption as wide as HTTP TLS, SSH, DHCP, DNS

chubot 11y ago
Why does SSH have v1 and v2? Honest question, I don't know the protocol. I would guess it's because v1 was too brittle to be upgraded. SSH and TLS have very few implementations... and there also seem to be incompatible versions there, at least with SSL 2.0 and 3.0. That approach might work for the ecological niche of those protocols, but I don't think it would have worked for HTTP. There are orders of magnitude more HTTP implementations than DNS, DHCP, TLS, SSH, etc. That's one reason for its wide adoption.
- magila 11y ago
  The different versions of SSH and TLS came about because the protocols' semantics needed to be revised in non-backwards compatible ways to resolve security issues. This has nothing to do with the format of the protocol. I would remind you that HTTP has also had similar revisions (0.9, 1.0, 1.1). Hyperbole about "orders of magnitude" aside, I'm not sure having a very large number of implementations should be seen as a plus. Protocols like SSH, DNS, and DHCP have relatively few implementations because the vast majority of use cases are covered perfectly well by a handful of existing libraries and tools. By comparison HTTP implementations tend to be ad-hoc and tightly coupled.
  - chubot 11y ago
    HTTP 1.1 is backward compatible with 1.0, and I'm pretty sure 0.9 is. I think with SSH and SSL they basically have an (if version) statement at the top level, and then enter a completely different codebase for each version. They can get away with this because there are so few implementations. With HTTP you had more graceful upgrade. They made "mistakes" but were able to accomodate it within the existing structure.

by magila 11y ago

chubot 11y ago

Why does SSH have v1 and v2? Honest question, I don't know the protocol. I would guess it's because v1 was too brittle to be upgraded. SSH and TLS have very few implementations... and there also seem to be incompatible versions there, at least with SSL 2.0 and 3.0. That approach might work for the ecological niche of those protocols, but I don't think it would have worked for HTTP. There are orders of magnitude more HTTP implementations than DNS, DHCP, TLS, SSH, etc. That's one reason for its wide adoption.

magila 11y ago
The different versions of SSH and TLS came about because the protocols' semantics needed to be revised in non-backwards compatible ways to resolve security issues. This has nothing to do with the format of the protocol. I would remind you that HTTP has also had similar revisions (0.9, 1.0, 1.1). Hyperbole about "orders of magnitude" aside, I'm not sure having a very large number of implementations should be seen as a plus. Protocols like SSH, DNS, and DHCP have relatively few implementations because the vast majority of use cases are covered perfectly well by a handful of existing libraries and tools. By comparison HTTP implementations tend to be ad-hoc and tightly coupled.
- chubot 11y ago
  HTTP 1.1 is backward compatible with 1.0, and I'm pretty sure 0.9 is. I think with SSH and SSL they basically have an (if version) statement at the top level, and then enter a completely different codebase for each version. They can get away with this because there are so few implementations. With HTTP you had more graceful upgrade. They made "mistakes" but were able to accomodate it within the existing structure.