I wrote: > What do you think of this wording: > > 2) ACE labels obtained from domain name slots SHOULD be hidden > from users except when the use of the non-ASCII form would cause > problems or when the ACE form is explicitly requested. Given an > internationalized domain name, an equivalent domain name containing > no ACE labels can be obtained by applying the ToUnicode operation > (see section 4) to each label. When requirements 1 and 2 both > apply, requirement 1 takes precedence.
"Eric A. Hall" <[EMAIL PROTECTED]> replied: > Was there a problem with the explicit text I provided? I prefer to be more concise. I tried to incorporate all the points I agreed with. The above wording is significantly less strong that the wording in the current draft. > The text presented here still encourages a default behavior of > transliterating anything that looks like a domain name, Not things that look like domain names, things that are known to be domain names. That's what the "obtained from a domain name slot" is for. And I added "except when the use of the non-ASCII form would cause problems". But yes, I still want users to be shown the non-ASCII form except when there's a reason for them to be shown the ACE form. > when it should be the opposite. I'm afraid I disagree. People have said in the past that IDNA is pointless if users always see the ACE form. The world you seem to be envisioning is one in which users would be seeing the ACE form an awful lot. > > We should be able to update mail user agents (like Pine) and > > immediately be able to use IDNs in email addresses without having > > to touch mail transfer agents (like sendmail) or DNS servers (like > > bind), and without having to wait for any updates to protocol > > specifications (like the DNS spec and the SMTP spec) or data format > > specifications (like RFC 2822). > > Not possible. > > We seem to have a disconnect here. Apparently. > "LDH slot"? Many generic domain name slots allow all ASCII characters, not just LDH characters. But "ASCII slot" is not appropriate either, because the essence of the concept is not what the slot allows or what standard it cites; the essence of the concept is what standard the slot does *not* cite, namely the IDNA spec. So the term needs to convey non-specialness or non-i18n-ness. If you don't like "generic" or "vanilla" or "ordinary" or "non-internationalized" or anything along those lines, then we're probably not going to find common ground. > The prohibition needs to be against all punctuation. For host names, right, not domain names in general? I think I like this model: Just as ASCII host names exclude many of the characters allowed in ASCII domain names, internationalized host names would exclude many of the characters allowed in internationalized domain names (the same sorts of characters: punctuation and symbols). There would be two stringprep profiles, nameprep with a small prohibition table, and hostprep with a large prohibition table. However, I think it's probably too late for this. I very much doubt that most people would be interested in making such drastic changes at this late date. Non-ASCII punctuation is not threatening enough to warrant derailing the process. AMC
