Re: [idn] proposed i18n naming rules

["Eric A. Hall" <ehall@ehsco.com>]

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.

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. 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.

[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.]

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/