Jumping into this discussion quite late, but... On Thu, Nov 19, 2020 at 4:39 PM Gould, James <jgould=40verisign....@dmarc.ietf.org> wrote:
> The 3 options presented and discussed at the REGEXT meeting included three > extension options, which all include an namespace URI in the greeting and > logic services: I'd really like to understand why there's not option (4), which, as i mentioned, would be: - Accept EAI addresses like any other email address in the standard EPP field (if the registry supports this). I don't see why the current RFC 5730 ff schema would not support this. - If a registry doesn't want to accept EAI addresses, return a 2306. This is inline with many other elements of registry policies - eg. when a registry validates the pc element of contacts against local policy, it would also 2306 - and nobody has yet discussed an extension for the purpose of announcing that the registry only supports a certain set of pc values (nooooo, no i've planted ideas in all of our brains!) - I don't see an issue with RDAP. RDAP can perfectly display non-ASCII characters - Creating an extension like this will never make EAI's "first class citizens". Accepting EAIs in standard "<email>" elements will. Maybe I'm failing to see the point. And, as Klaus said, we're making EPP based registries a super complicated beast, implemented by a very small community. Introducing "yet another switch" into the protocol won't make it easier. For example, what would an "old" client do that doesn't understand a potential EAI extension? Would they be deprived of email addresses completely, and receive non-sensical placeholders which they'd unwittingly hand over to their email system (even if that email system would perfectly understand EAIs?). Does sound like a failed opportunity to me! best, Alex _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
