[EMAIL PROTECTED] 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/
