Tatuya-san, Again, thanks for your interest and the review.
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. 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? The next rev of the I-D will keep ASCII (for now) but with the clarification about case, octal (or whatever), and the final '.'. Thanks again -éric On 04/10/17 19:02, "[email protected] on behalf of 神明達哉" <[email protected] on behalf of [email protected]> wrote: At Mon, 2 Oct 2017 14:04:47 +0000, "Eric Vyncke (evyncke)" <[email protected]> wrote: > - FQDN syntax... one previous version was requiring the DNS format but it was longer than the current ASCII format and more complex to parse by implementers. What do you mean by "it was longer than the current ASCII format"? As I pointed out in my own comment (https://www.ietf.org/mail-archive/web/int-area/current/msg06039.html) in the worst case textual representation of a domain name is way much longer than that in the binary form (1004 vs 255). I also doubt this: "more complex to parse by implementers". Textual representation of a domain name involves a lot more corner cases than the binary form, such as escaping special characters or the \DDD form. Perhaps the concern was not about parsing the binary form but about producing corresponding textual form to use it in a URL? If so, yes, that can be tricky. But since you would need to validate the complicated textual form if you received a textual domain name in RA anyway, I don't think that is a valid argument to adopt the textual form. (I'm not necessarily arguing for the binary form, but so far I simply don't see a sensible reason for the choice). -- JINMEI, Tatuya _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
