(Having quickly scanned through the thread to catch up.) CLASS has been problematic since the start. The first "mistake" made was encoding the CLASS field after the OWNER NAME field in a resource record. This meant that all domain names have to be encoded and treated the same regardless of class, removing an important functionality that would have encouraged better development of CLASS concepts.
Had the CLASS field come before OWNER NAME, I believe that its history would be different. I.e., it would have been used and not ignored. Much as message compression, there was a time when it was proposed and used, then it went through an era where it was assumed/forgotten before once again becoming an issue during the latter phases of DNSSEC development. The result of that historical path was two sets of intertwined RFC revisions differing on the topic before finally being discovered, if I recall correctly, when the unknown types RFC (3597, see section 4) was developed. What I mean to say here is that over the decades, the collection of volunteers that made up DNS WG, DNSSEC WG, DNSIND WG, DNSEXT WG, and this one haven't consistently applied the same frame of reference to the protocol. Unless we wiped all DNS code from existence, I don't see how we could ever engineer a path to a "Clarifications of the CLASS" in the DNS protocol. Unlike other loosely defined items in STD 13, CLASS was so poorly formed I can't see saving it past current use. I wasn't aware of the mentioned (in the thread) effort to use a different CLASS for IDN, but the idea had come to me (as in 'across my desk' from someone else) a long time ago too. It wasn't apparent that it could even work given the ordering of the fields in the resource record.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
