"Adam M. Costello" 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. Was there a problem with the explicit text I provided? The text presented here still encourages a default behavior of transliterating anything that looks like a domain name, when it should be the opposite. We seem to have a disconnect here. You're concerned with the symptoms, I'm talking about the root cause. Every protocol and data-format has its own specific considerations, and it is not possible to mandate (or strongly suggest, if you prefer) that every Internet service change its behavior to suit IDNA. It's absurd. The only thing you can do here is say "don't do anything until the masters of the spec say how to do it". Again, consider WHOIS output. Should a WHOIS server transliterate output? Should it be performed at the client so that negotiation is not required? And you have described the protocol negotiation or client behavior where? Or consider HTML, which has a limited notion of PDU structures. Should domain names enclosed in HREF tags be transliterated? or should IDNA never be transliterated, and if a user wants an i18n domain name to be displayed then they should use the charset capabilities for this? And you have documented this behavior for the W3C developer community where? Even if you want to limit this behavior to a very specific community, something small and syntactically precise such as email header fields, which header fields should do this? Should this be limited to the originator and recipient header fields only? And you have documented this extension to RFC 2822 where? I mean, even RFC 2047 is restricted to specific data-types. You only have one choice here: nobody transliterates nothing until the governing specifications for the network service in question clearly describe how it should be done. The exception is local presentation of connection identifers. There is no reason that ping shouldn't be able to handle IDN<->IDNA conversion, although even that has to be handled with care. Look, I can't even tell one of my newsreaders to use an i18n domain name since the .newsrc files are shared by multiple clients. > the design of IDNA was this one: 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. See above. > > The use of "generic" is what bothers me, because it implies that the > > slot (another word I dislike) can hold any domain name. > Other words that could serve the same purpose are "vanilla" and > "ordinary". Would either of those be better? Or maybe > "non-internationalized". "LDH slot"? > > So you have an example of another WG specification where only half > > the opinions are provided, and that they provide value towards > > understanding the protocol or service? Citations Please > > Not an IETF spec, but the PNG spec includes a rationale appendix, and > we've received comments saying that it was helpful and it would be nice > if other specs did the same. I don't think we ever received comments > saying it should not have been included. If it wasn't lop-sided opinion (aka religion), you probably wouldn't have gotten the two complaints you got here either. > > It is also factually in error. > > If that's true, it should be fixed. | Many proposals for IDN protocols have required that DNS servers be | updated to handle internationalized domain names. Do you honestly seriously believe that IDNA will not require upgraded servers to handle transliteration on input? That it *CAN* work without an upgrade does not mean that it *WILL* work without an upgrade. Which of those words is a property of "required"? Both. | Because of this, a person who wanted to use an internationalized | domain name would have to be sure that their request went to a DNS | server that had been updated for IDN. The two dual-mode proposals before this WG have both allowed legacy servers to provide answers. False. Etc. The logic-path is entirely corrupt and based on nothing more than an opinion that an encoding which appears nowhere else in the known universe is somehow better than embracing the pain of an incremental upgrade. > > A prohibition against combining characters is not feasible. See > > <[EMAIL PROTECTED]> from K Whistler. > > He said that we could not simply prohibit combining characters, and > I agree. I was suggesting that we might want to prohibit *initial* > combining characters. Combining characters combine with the character > preceeding them, so a label beginning with a combining character is a > strange beast, and might cause bizarre and suprising behavior. When rendered, it will combine with the dot separator. However, that's only half the complaint. Also consider that leading punctuation is often used as a command-line qualifer (-verbose). The prohibition needs to be against all punctuation. When I looked (very briefly, that was composed at a hotel room), the characteristic that seemed most useful was a property of diacritical mark or dashes. I don't think there is a property of punctuation. I should look. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
