In message <d1c00201.cb7f%edward.le...@icann.org>, Edward Lewis writes: > Content-transfer-encoding: 7bit > > (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.
Yet this is clearly not so. We have had different label encodings like bit-string labels. Only the recursive server, zone server and immediate parent zone were required to support the encoding. It was desirable for all the other parents to support the encoding. Think qname minimisation for why this was so. bit-string labels were a pain for other reasons so I was happy to see them go. I never got around to writing the code the code to lookup the suffix of non bitstring labels to prime the cache with the parent server's NS records but I had thought about doing it. It was basically self evident that this needed to be done. Similarly one can choose not to use compression labels all the time. Named does this to preserve case in responses by only using compression when the case of the suffix label sequence also matches. One could say that class X (or a label type) uses utf8 (or any other character encoding) without compression and just use libraries and tools that know this. Similarly we could have just extended the header by using a opcode to signal a extended header structure for EDNS. Servers that are not aware of the extended header structure would have just returned FORMERR. All of these are incrementally deployable. > 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. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
