Re: Document Status?
John C Klensin <[email protected]>
| Newsgroups | gmane.ietf.idn |
|---|---|
| Message-ID | <156536501.1031483606@localhost> |
--On Sunday, 08 September, 2002 01:06 +0000 "Adam M. Costello" <[email protected]> wrote: > John C Klensin <[email protected]> wrote: > >> while I don't think any of us would encourage it, it would be >> plausible for the administrator of a particular zone (or >> subtree) to say that "1" and "l", and "u" and "v" are just >> too similar, and hence that no labels containing "1" or "v" >> are permitted to be registered in that zone. > > Yes. > >> it would be completely unacceptable for that zone >> administrator to expect that a query containing "ab1cd" be >> mapped into, or interpreted as, a query containing "ablcd", >> or that information associated with "ablcd" be returned in >> response to a query for "ab1cd". > > Not even if the registry told everyone up front that this is > how it would operate? As long as registrants understand that > the resource records they associate with ablcd will be > automatically mirrored under ab1cd, what's the problem? > Registrants who don't want this auto-mirroring (like me) can > go to a different registry. I don't want to go back into an area in which the dead horse has already been kicked into an unrecognizable pulp, but, no, your exceptions don't work. From a technical standpoint, if a registry wants to implement that mirroring by automatically registering ablcd IN CNAME ab1cd whenever they get a registration for "ab1cd" and refusing to accept registrations for "ablcd", then nothing prevents that (but the combinatorics, which would, IMO, rapidly kill the idea, and even more quickly in IDN-space). Such registrations don't change the DNS protocols or algorithms. But if the registry starts doing protocol-variations, and "telling everyone up front", it means that every caching server has to know _all_ of the per-zone rules. And, remember, nothing makes a TLD or SLD sacred -- if we can have different resolution/matching rules for KR than for COM, then we can have different matching rules for the one subdomain/zone in TV (if it exists) that is reserved for domestic registrations than we have for all of the foreign-sales ones. And I can have different rules for the i-klingon.jck.com zone relative to the zh-wuu.jck.com zone, and still other rules for the jck.com default (and no one can constrain me to name them that way and thereby give hints). >> If the relevant zone accepts dynamic updates that can add >> labels to the zone, we need to be absolutely sure that there >> are appropriate and unambiguous reply states for "that label >> isn't acceptable for this zone even though it meets all of >> the syntax rules". > > This is not an IDN issue; per-zone acceptable-name policies > and dynamic updates both existed before IDN. If anything, > this is an issue for the dynamic DNS update spec, not the IDN > spec. Here we may rather seriously disagree. The IDN WG has a fairly explicit mandate to not do anything that would wreck the DNS. Taking this as an example, to the extent that "dynamic updates ... existed before IDN", then it is _someone's_ responsibility to be sure that IDN side-effects don't foul it up, or that there are enough normative crossreferences to be sure that IDN specs are not published onto the Standards Track until after dynamic DNS is updated sufficiently to resolve any problems. If the WG isn't going to, or cannot, take responsibility for doing that, it falls onto the IESG to do the necessary coordination. But, at least in my opinion, if anything the IDN WG produces moves onto the standards track that creates identifiable risk to existing standards (or even well-established practices), without documenting and attempting to resolve those issues on the "someone else's problem" theory, then it is a process violation as well as a Really Bad Idea. john