3 ms·

Like utf8... which mDNS supports: https://tools.ietf.org/html/rfc6762#appendix-F https://tools.ietf.org/html/rfc6762#appendix-F I’d personally love to see a pr

Like utf8... which mDNS supports: https://tools.ietf.org/html/rfc6762#appendix-F https://tools.ietf.org/html/rfc6762#appendix-F I’d personally love to see a proposal to drop puny-code and adopt utf8.

fiddlerwoaroof 6y ago
UTF-8 is problematic because of lookalike codepoints. (And the current practice of decoding punycode has similar issues: how exactly international domain names should work seems to me like a really hard problem)
- bluejekyll 6y ago
  I see this argument a lot. I understand it, but I don’t agree with it. One issue that I see is that the UIs where this is rendered, render the utf8, ie the look alike code points. So if it’s to protect users, then we’d need to present the puny-code and not the rendered native language text. But, why would do this? It would defeat a primary reason for DNS, to bridge humans to networks. So I just don’t buy it. So the look alike issue is still there. So if it’s not the users, then who are we protecting from the look-alike characters? It’s definitely not a benefit for those of us who’ve written the code to parse and store DNS names (at least from my personal perspective).
  - fiddlerwoaroof 6y ago
    Browsers use heuristics here and display the punycode when it conflicts with a more "likely" domain: e.g. in the cross-script spoofing here: http://unicode.org/L2/L2004/04305-spoofing.html http://unicode.org/L2/L2004/04305-spoofing.html , Safari on macOS displays http://xn--tp-jbc.com http://xn--tp-jbc.com as "xn--tp-jbc.com" but http://xn--t-zfa.com http://xn--t-zfa.com as "ät.com"
    - bluejekyll 6y ago
      Sure, disambiguation is important, but do we need to do that at the serialization level? We increase the parsing and transformation costs in DNS, when it seems like what we really need is clear rules about what unicode values are legal and which are not. The example of umlaut is really good one though, as the umlaut can be an extra code point, or part of the actual character. I can see why we'd want to be explicit that both are not allowed in DNS... It still feels like we're solving this issue at the wrong layer, i.e. the protocol layer, as opposed to the application layer. I'm 100% in agreement on needing solutions here, but I think your example illustrates that it's a higher-order issue for applications, and not the protocol.
- a1369209993 6y ago
  That's a problem with Unicode (including punycode), not with UTF-8.

fiddlerwoaroof 6y ago

UTF-8 is problematic because of lookalike codepoints. (And the current practice of decoding punycode has similar issues: how exactly international domain names should work seems to me like a really hard problem)

bluejekyll 6y ago
I see this argument a lot. I understand it, but I don’t agree with it. One issue that I see is that the UIs where this is rendered, render the utf8, ie the look alike code points. So if it’s to protect users, then we’d need to present the puny-code and not the rendered native language text. But, why would do this? It would defeat a primary reason for DNS, to bridge humans to networks. So I just don’t buy it. So the look alike issue is still there. So if it’s not the users, then who are we protecting from the look-alike characters? It’s definitely not a benefit for those of us who’ve written the code to parse and store DNS names (at least from my personal perspective).
- fiddlerwoaroof 6y ago
  Browsers use heuristics here and display the punycode when it conflicts with a more "likely" domain: e.g. in the cross-script spoofing here: http://unicode.org/L2/L2004/04305-spoofing.html http://unicode.org/L2/L2004/04305-spoofing.html , Safari on macOS displays http://xn--tp-jbc.com http://xn--tp-jbc.com as "xn--tp-jbc.com" but http://xn--t-zfa.com http://xn--t-zfa.com as "ät.com"
  - bluejekyll 6y ago
    Sure, disambiguation is important, but do we need to do that at the serialization level? We increase the parsing and transformation costs in DNS, when it seems like what we really need is clear rules about what unicode values are legal and which are not. The example of umlaut is really good one though, as the umlaut can be an extra code point, or part of the actual character. I can see why we'd want to be explicit that both are not allowed in DNS... It still feels like we're solving this issue at the wrong layer, i.e. the protocol layer, as opposed to the application layer. I'm 100% in agreement on needing solutions here, but I think your example illustrates that it's a higher-order issue for applications, and not the protocol.
a1369209993 6y ago
That's a problem with Unicode (including punycode), not with UTF-8.