4 ms·

Oh, "same as" cases are indeed all over, e.g. the EUI-64 https://standards.ieee.org/develop/regauth/tut/eui64.pdf https://standards.ieee.org/develop/regauth/tut

by ay 12y ago

Oh, "same as" cases are indeed all over, e.g. the EUI-64 https://standards.ieee.org/develop/regauth/tut/eui64.pdf https://standards.ieee.org/develop/regauth/tut/eui64.pdf I was looking for the example of the sparkly unicorn protocol from 2000 the people seem to evoke, which does not need any knobs and is available on every device to update some other protocol from 1970s. (I suppose the hard meta-question to protocol designers is: how do you make sure your children will not hate you for the protocol you have imposed on them today ?)

wbl 12y ago
UTF-8 updating ASCII is probably the best example of this going well. And even then there was a terrible mistake made in the design of Korean encodings which had to be fixed.
- taejo 12y ago
  What was the problem with Korean encodings?
  - drdaeman 12y ago
    I have no experience with Korean and Unicode but, I guess, it's jamo composition? With it, there are two distinct and not-really-compatible (since anyone in real world practice rarely cares about Unicode normalization) ways to specify a single Hangul character. And that should make text processing a bit painful.
    - jrochkind1 12y ago
      Anyone who writes software to deal with unicode really better care about unicode normalization! You are going to have all sorts of edge case bugs and unexpected behaviors if you don't, definitely not limited to Hangul. There are multiple un-normalized ways to write all sorts of on-screen glyphs, including Latin alphabet ones.
    - taejo 12y ago
      I thought wbl meant something to do with the combination of Korean and UTF-8, whereas jamo composition is no more related to UTF-8 than any other unicode encoding.
  - wbl 12y ago
    They moved the Korean encodings at one point in the early 1990's. Luckily this was before anyone used it, but it was still a big mess. I don't know why they had to move it.
- ay 12y ago
  Both yours and tedunangst example (SSH) have one important commonality which is not present in IP: they become immediately available to two parties as soon as these two parties upgrade. With IP, all the intermediate nodes need to upgrade to use the new protocol (tunneling tricks aside). This difference would probably be a significant factor in the speed of adoption. Tunneling obviously can emulate the 2-party model, but then we're left with the problem of managing the crazy amount of tunnels (and security issues) and sunsetting them. Now if the ideas like http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-05 http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-... were discovered/implemented a decade ago - could that have been used to turn an N-party transition problem into a 2-party transition problem ?
tedunangst 12y ago
The first version of ssh was released about the same time as the first IPv6 RFC.
- ay 12y ago
  ...and thanks to the knobs for being able to workaround the day1 bug uncovered just this year in at least one of the widely used vendor's server implementations while getting the fix. But yes, with just 2 parties involved into any instance of the protocol enabling easy upgrade/downgrade path, and tight engineering it is indeed a beautiful protocol.

by ay 12y ago

wbl 12y ago

UTF-8 updating ASCII is probably the best example of this going well. And even then there was a terrible mistake made in the design of Korean encodings which had to be fixed.

taejo 12y ago
What was the problem with Korean encodings?
- drdaeman 12y ago
  I have no experience with Korean and Unicode but, I guess, it's jamo composition? With it, there are two distinct and not-really-compatible (since anyone in real world practice rarely cares about Unicode normalization) ways to specify a single Hangul character. And that should make text processing a bit painful.
  - jrochkind1 12y ago
    Anyone who writes software to deal with unicode really better care about unicode normalization! You are going to have all sorts of edge case bugs and unexpected behaviors if you don't, definitely not limited to Hangul. There are multiple un-normalized ways to write all sorts of on-screen glyphs, including Latin alphabet ones.
  - taejo 12y ago
    I thought wbl meant something to do with the combination of Korean and UTF-8, whereas jamo composition is no more related to UTF-8 than any other unicode encoding.
- wbl 12y ago
  They moved the Korean encodings at one point in the early 1990's. Luckily this was before anyone used it, but it was still a big mess. I don't know why they had to move it.
ay 12y ago
Both yours and tedunangst example (SSH) have one important commonality which is not present in IP: they become immediately available to two parties as soon as these two parties upgrade. With IP, all the intermediate nodes need to upgrade to use the new protocol (tunneling tricks aside). This difference would probably be a significant factor in the speed of adoption. Tunneling obviously can emulate the 2-party model, but then we're left with the problem of managing the crazy amount of tunnels (and security issues) and sunsetting them. Now if the ideas like http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-05 http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-... were discovered/implemented a decade ago - could that have been used to turn an N-party transition problem into a 2-party transition problem ?

tedunangst 12y ago

The first version of ssh was released about the same time as the first IPv6 RFC.

ay 12y ago
...and thanks to the knobs for being able to workaround the day1 bug uncovered just this year in at least one of the widely used vendor's server implementations while getting the fix. But yes, with just 2 parties involved into any instance of the protocol enabling easy upgrade/downgrade path, and tight engineering it is indeed a beautiful protocol.