Klaus, The EAI address issue applies to more than RFC 5733 (RFC 8543 and Email Forwarding Mapping at a minimum) , where even if creating a new version of RFC 5733 made sense, it would not solve the broader issue. The EPP extension option would be straight forward and can be applied across multiple EPP objects with no need to directly revise the EPP object specifications.
There are three EPP extension options that have been discussed with different scopes (session-level, object-level, and element-level). The current EPP extension draft (draft-belyavskiy-epp-eai-02) defines the element-level scope, since you specify the element using the placeholder text along with the extension that contains the value for the element. The object-level scope would be handled via a marker extension, where the application of EAI is applied to any e-mail element in the object. The session-level scope would be handled via the greeting and login services, where all objects accessed in the session has EAI applied. -- JG 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/> On 11/20/20, 12:32 PM, "regext on behalf of Klaus Malorny" <regext-boun...@ietf.org on behalf of klaus.malo...@knipp.de> wrote: On 20.11.20 14:37, Taras Heichenko wrote: > >> Right - it's a lot MORE work. > > Let's ask Klaus what takes more developer's work, changing namespace, or adding the extension generation and parsing. > (In the neighbor thread Klaus wrote that his company is developing EPP software.) > Hi, well, for the first case our EPP toolkit already allows the use of the domain, host and contact objects with different XML namespaces. The changes would mostly comprise creating subclasses for the respective commands and responses that simply override the previous (RFC 5733) namespace, since the schema would not change. This is less work than creating a brand new extension. For the registrar system, I would have to introduce a configuration parameter to select EAI support in any case. For the login process, the work would also be more or less the same. For the code actually issuing the contact commands only changes for the creation of the toolkit objects would be required in the first case, whereas the extension version would require additional logic to create the extension resp. check for the presence of the extension and fiddle around with it. This is some more work and an additional source of bugs. For the namespace solution, when some time in the future all supported registries have phased out the RFC 5733 contact object, I could clean up my code. In contrast, the code for the extension would stay forever and clutter up my code. Klaus _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1tkGH6yshJslX1H5rVyXef-gmOiwGQeI0_cj3OyHX2bcGTjTg8If_ia4I63uvt3fg1dKwJA0lhLt2KjU5BCLariU_4ie_g1e23LXAWTBGr6Ze2MvlYNEKKCFJH4CMisS6_E0yvIieNlzR_-I7dmV4p09aVqy_kUK3BWH5XPM73nVJvvRMv9UpseKXuI6osj4DifG7m6Czmysg08IivFORmQPOW1ZS8FJt9sLcO9gS-RkXsi6YYcbdCxD3BYea2YCoHY5BKgKU1l64GLASpPgfq4eMYuGjsL6YiIBp_kbduRM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
