Jinmei, > On Oct 11, 2017, at 10:29 AM, 神明達哉 <[email protected]> wrote: > > At Wed, 11 Oct 2017 13:57:57 +0000, > "Eric Vyncke (evyncke)" <[email protected]> wrote: > >> Regarding the way to represent the FQDN, the authors do not have any >> hard position. It seems to us that plain ASCII is easier and >> shorter. > > "Shorter" is clearly incorrect regarding the worst case. "Easier" may > be a subjective concept, but I personally don't think it easier to > handle all the corner cases of parsing textual domain name > representation. > >> You have a good point that we need to make it clear in the text that >> "foo.com" is the same ID as "FoO.CoM" or as "foo.com." (unsure whether we >> want to go to the octal representation). >> >> FQDNs as plain ASCII are shorter than 'compressed DNS format' when written >> in a usual way using ASCII without any octal escape, or, did I fail to >> understand you? > > I'm not sure what "compressed DNS format" means. But if you're > talking about textual vs binary representation of a domain name, > it is correct that the textual form without any escaping is shorter > than the binary form. But the difference is minor - it's just one or > two octets shorter (one if the textual form contains the trailing dot, > two otherwise). And, in the case of > draft-bruneau-intarea-provisioning-domains-02, if it contains the > trailing nul octet, it's just zero or one octet shorter. > > Example: a textual (and shortest) representation "a.example.com." > consumes 13-15 octets (depending on whether to contain the trailing > dot or the trailing nul). Its binary form always consumes 15 octets. > > btw, I'd note that RFC8106 uses the binary representation of domain > names for the DNS search list option. I guess the pros and cons on > text vs binary should be largely the same - an implementation of > RFC8106 also needs to parse the value and is quite likely to dump it > in the textual form, and the data length could be a concern as an RA > option. If we were okay with the binary form in RFC8106, I don't see > why we aren't for draft-bruneau-intarea-provisioning-domains.
I agree. Further, I think there would have to a very good reason to do something different that how RFC8106 handles this. Having two different ways to encode DNS info in RA options seems like a very bad idea. Thanks, Bob
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
