Tobias, According to RFC 2606, example.com/net/org are reserved for examples. We need an placeholder value in the protocol itself. I view the use of the RFC 2606 domains in the protocol itself as an issue and not a solution. The empty.as112.arpa domain is meant to be blackholed by protocol, which meets one of the requirements. The use of the placeholder value will only be needed until all clients and servers support EAI. It’s a corner case, but it needs to be defined to address use cases like the handling of the required RFC 5733 email element when the other side of the connection doesn’t support EAI and all that exists is an EAI address.
Thanks, -- JG [cid:image001.png@01D781E8.DFD80130] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Tobias Sattler <satt...@united-domains.de> Date: Saturday, July 24, 2021 at 3:21 AM To: James Gould <jgo...@verisign.com> Cc: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-eai Predefined Placeholder Email Value Hi Jim, I am not into all details, but why not using an email adress, such as e...@example.com? My understanding of RFC2606 is, that you can use example.com/org/net for that purpose, too, as they are reserved TLDs. empty.as112.arpa has no MX record, too, therefore, I don‘t get the advantage of it. Best, Tobias Am 22.07.2021 um 18:06 schrieb Gould, James <jgould=40verisign....@dmarc.ietf.org>: There is one TBD item that exists in section 5.3.2 of draft-ietf-regext-epp-eai related the “predefined placeholder email” that is used by the EAI supporting server and EAI supporting client where the opposite party doesn't support EAI. In both cases a valid email value needs to be provided to a non-EAI supporting client or server to satisfy a required email property when all that is available is an EAI value. To satisfy this requirement, a predefined placeholder email needs to be selected that meets the requirements: 1. A syntactically valid email address to pass client or server validation logic. 2. A non-EAI email address since the client or server doesn’t support EAI email addresses. 3. A single value that can indicate the lack of EAI support to the client or server. 4. An email address that is blackholed and never delivered. 5. Use of the email address will not cause operational issues. RFC 7535 defines a blackholed domain name with EMPTY.AS112.ARPA, which can be leveraged for the EAI predefined placeholder email. The proposal is to define the “predefined placeholder email” value as e...@empty.as112.arpa<mailto:e...@empty.as112.arpa>. This value looks to meet the requirements. We are looking for feedback from the working group as well as experts outside of the working group to help determine whether the value does meet the requirements and whether there are additional requirements that need to be considered. Once the predefined placeholder email is agreed to, the draft will be updated to define the predefined placeholder email value and use that value to replace the existing TBD values in section 5.3.2 of the draft. Thanks, -- JG <image001.png> James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/13Qmkpjt7ftL37EMa9W53e_z6Y6RWCZMv6oXbQkvZ4Gj9zBVGuA0uR56C4fUz4Hv4xAIWvNLrxAB4318rn5NGxwhTKcpjgbUAJMoVoejUpJIse3-ovUqfsqC_xq8e4866ZmCUnO_vHq6VO6SqojYrkO9bCEdcK5DZY37H-o46Gi0iqEa-5hZVKHeERBy_gDnmAwgUxa-m61JVpKUlqUU5YfdAPWyHAcwqeppi7DjdeECQ50K7bt1qCtKOXviMvLvXU2g7E38BA-kexatIDlu7NA/http%3A%2F%2Fverisigninc.com%2F> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
