James Seng/Personal wrote:
> Our opinion on host vs domain name isnt really different :-). The > question is which one do we do? Or both? All are valid answer. The encoded values being passed around are supposed to -decode- as UCS character codes, so it would seem best to maintain consistency across all outputs. We do not want to make it more complex than necessary and defining multiple extraction profiles would make processing much more complex: "we promise that this encoding will represent a series of UCS characters" should be it. For that reason, my opinion is that any UCS character code (including those not yet assigned) should be valid for internationalized domain names (with nameprep providing the host name subset filter). Going that route incurs a responsibility to tell implementations that they have to be careful with data they process, but in truth we had that responsibility already given the broader exposure of the combining characters. > Do we need more than one IDN label encoding that protocols and > applications can use to store and represent i18n domain names? I would submit that we are describing transfer encodings and their handling. The application media being used to transfer the encoded values provide seven- and eight-bit paths. For the sake of maximum efficiency with the applications that transfer and use the domain names, we should provide seven- and eight-bit encodings. The encapsulation constraints in DNS are difficult to work with but that does not change the above. We should not be defining mandatory seven-bit encodings for eight-bit applications especially if they are compliant with BCP18 for every unit of protocol and/or application data. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
