Re: [idn] proposed i18n naming rules

[Mark.Andrews@isc.org]

> 
> Mark.Andrews@isc.org wrote:
> 
> > Mailboxes after the first label are subject to the same contraints
> > as hostnames.  I would also argue that SRV ownernames are also
> > subject to the same constraints as hostnames once you remove the
> > first two labels.  In otherwords you can't assume that one set
> > of rules about what is legal applies to all labels in a domainname.
> 
> Some points on this after having thought about it some. Overall, I think
> the issues you raise have to do with the use of IDNs as protocol data and
> are not necessarily problems with the syntax. As such, the proper place to
> fix these problems would be in the protocols.
> 
> First, there is nothing in RFC 2782 that says SRV lookups "should ensure
> the rest of the FQDN is legitimate." But this text (and probably some
> specific guidance) SHOULD be there. In that regard, a malformed lookup for
> an SRV entry in an IDN hierarchy will work exactly the same as a malformed
> lookup for an SRV entry in an STD13 hierarchy: they will both fail.
> 
> The fix to this problem (and others like it) is to fix the source: "if you
> want SRV lookups to succeed (regardless of whether they are IDNs or STD13
> DNs), make sure the rest of the FQDN is legitimate." A more specific
> solution would be to suggest that clients treat labels to the right of the
> protocol elements as hostname labels, and to reject those which do not
> conform to [LDH|IHI] rules.

	That's why I said that I would *argue* that it should be that way.

> 
> As for email addresses in SOA and RP RRs, those are provided as part of
> the RR data and are not specified in queries; queries for them cannot be
> formed so queries for them cannot break.

	They have been in the past (see MB).  And could be in the future.

	Mailboxes are how you reference people, rather than hosts,
	by name in the DNS.  They arn't expected to have address
	records or MX records but are expected to have other types.

> The proper place to deal with IDNs as RR data is when the domain name is
> added to the zone.
> 
> For all other protocol uses of IDNs, a word of advice on this point is in
> order, but the protocols should be fixed.
> 
> I guess I'm saying that I don't see the issues you raise as inherent
> problems with the syntax structures, since the conflict is not the syntax
> but in the protocol operations that utilize the syntax. The protocol
> operations is the appropriate point of focus.

	You can't have labels undergoing different transformations
	depending upon what is being looked up.

	The only thing that can change between a IHN and a IDN is
	that IDNs that are not IHNs should be rejected by the
	lookup tools.  Similarly the zone maintence tools should reject
	(by default) IDNs that are not IHNs when used in a context that
	requires a IHN.

	Mark

[OT for this particular discussion, but I will add the above changes to
> the next rev of the dual-mode draft when I add the new syntax rules.]
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org