James Seng/Personal wrote:
> It become more apparent that it is dangerous to into the discussion of > internationalized domain names vs internationalized host names. Such > discussion is half-technical and half-policy and this group may not have > sufficient information to determined what is a considered a valid > hostname, and that is subjective to registries. I don't want to make a big deal out of this point, but I would like to say that the distinction is required for basic functionality. For example, SRV entries use underscore, which is not a permitted character in nameprep (rightly) for use with host names, so domain names and host names have to be defined individually if both are to function. The distinction is not that fuzzy. Domain names are simply sequences of octets, while host names are those domain names which identify connection targets (either in part [relative] or in sum [FQDN]) and which conform to the rules provided by RFC952, STD3 and STD13. We really need to define i18n equivalents in order to meet the requirements of the DNS community. > > 4) Provide proposals to DNSEXT for handling these label encodings > > in the DNS service. > > > > [ ] yes > > [ ] no > > Longer term goal maybe. My understanding (which may be wrong) is that DNSEXT is leaving specification to us but reserving the right of ratification. Some work is likely to be required. If the IDN WG task list will be fluid this will show up sooner or later so I'm not going to argue the point. > > 5) Provide guidelines for the protocol and data-formatting groups > > to use when they extend their services to tag, store, decipher > > and/or display (as necessary) these encodings. > > > > [ ] yes > > [ ] no > > Care to explain a bit more? Defer all display processing, but give guidance on basic elements such as boundaries and illegal conditions. For example, we know that seven-bit domain names cannot be encoded in ACE, are harmful when provided, and MUST be discarded when discovered, and this information has to be relayed to other working groups. > Define an IDN label encoding that protocols and applcations can used to > store and represent i18n domain names. I see this as an opportunity to establish the consensus, which would facilitate finite deliverables for the WG. We can cut the overall timeline down if we go through the pain once and for all. Once we can agree on the objectives, arguing over deployment mechanics is a lot less stressful (hopefully). We really should come to terms with the objectives first, or else this will remain a perpetual open issue. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
