> As a user, I would not want to enter JSON into an RDAP client to do a > lookup. A simple and transcribable string is much easier to use.
I never suggested that. The JSON structure is what is exchanged on wire, it is independent on the kind of UI you want to present to your users. > I don't believe the goal here is to define more structure for entity > identifiers. RDAP already provides URLs for entities, and that is > probably enough structure. There does not need to have more structures... as everything is there already I believe with PublicID defined in 4.8 of RFC7483 > All that said, I understand your hesitation here. This draft takes an > unstructured field already in use and applies structure to it. That > could be problematic, and care must be taken. Doing such a thing is not > ideal, but we wouldn't be the first to do so. The xn-- signifier for > IDNs comes to mind. I agree... except that when IDNs were introduced there was already a not so small population of clients (DNS resolvers) that had to be taken into account. RDAP is still young, and far less used than whois. I was amazed to see in fact just by chance that very recently many blogs tried to make it more known, such as: https://blog.apnic.net/2017/08/11/2017-still-whois-whats-holding-back-rdap/ https://www.farsightsecurity.com/2017/11/17/stsauver-rdap/ Like you say, the summary for me is that adding a structure into an unstructured field after the fact is problematic. The problem is on the table, but it may be decided it is irrelevant or too late based on current deployments. I of course agree, I just think it is best to be clear about it. But if noone else speaks about it, case closed. BTW even for DNS, there are also discussions/interrogations showing that changes like IDNs to a core protocol were not necessarily the best choice. See https://datatracker.ietf.org/doc/draft-klensin-dns-function-considerations/ (a very interesting read for history decisions) -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
