Alex, How to handle input EAI values (create or update) can result in an error (e.g., 2306) based on server policy independent of the use of the extension. The extension provides for signaling by the client of the EAI support, which enables the server to fast-fail when it's not allowed. The EPP extension options (session-level, object-level, element-level) provide different levels of fast-fail support, where the session-level really doesn't enable the server to fast-fail on a per-TLD, per-object, or per-element basis. The object-level and element-level options using the marker extension does enable for the server to fast-fail on create or update.
What happens to old clients that don't support the EAI extension is an unhandled namespaces issue. Section 5 "Usage with General EPP Responses" of draft-ietf-regext-unhandled-namespaces defines an approach for a typical EPP extension (e.g., DNSSEC extension); although the question is what to do about the email element in the base object (e.g., return the EAI value, don't return the EAI if it's optional, return a placeholder value). The email element is required in RFC 5733, optional in RFC 8543, and can be either in non-RFC EPP extensions. What harm is there in returning an EAI value to a client that may not support it? It would not result in an XML parsing issue, but it could result in a processing issue, such as storage and use of value. Based on the potential for processing errors, I would choose to use to include an indication of the lack of EAI support using draft-ietf-regext-unhandled-namespaces, and I would not return the email element in the base object if it's optional and would be forced to use a pre-defined placeholder value in the base object if it's required. The pre-defined placeholder value should fast-fail as opposed to returning an EAI value that may result with non-deterministic results. I believe how to handle the email value in the base object is consistent with any of the EPP extension options (session-level, object-level, or element-level). The use of a placeholder value currently only applies to the element-level option, but may need to be defined for the session-level and object-level options for this use case. The server implementation considerations can be covered in the draft. Thanks, -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/23/20, 1:04 AM, "Alexander Mayrhofer" <[email protected]> wrote: Jumping into this discussion quite late, but... On Thu, Nov 19, 2020 at 4:39 PM Gould, James <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/regext
