On 7/6/15, 18:26, "Mark Andrews" <ma...@isc.org> wrote: >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.
We have had 1 different label encoding, called bit-string labels. There were only 2 bits for label type. 0b00 normal, 01 compressed. 10 was defined for a bit-string and "Future expansion." 11 has been left untouched because bit-strings weren't workable. >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. But no one did. Once we fell into the mud over bit-strings I recall us deciding not to burn '0b11' unless we had a really cool idea. >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. We could have done a hundred hacks. But we didn't. I'm theorizing we might have, had the CLASS field been before the owner name and not needed what has amounted to be "ugly hacks" to have different encoding schemes. But what might have happened doesn't matter as much as the CLASS "concept" not being really useful.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
