> 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.
Our opinion on host vs domain name isnt really different :-). The question is which one do we do? Or both? All are valid answer. > 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. Hmm, good point. I agree with the concept of doing so. I am not sure of the exact mechanism to do so tho but that is what a goal is for ;) But I do see this as the goal for the next step when we have one. > > 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. Okay, then I have one more questions before (2) & (3). Do we need more than one IDN label encoding that protocols and applications can use to store and represent i18n domain names? -James Seng
