On Fri, Nov 20, 2020 at 2:17 PM Hollenbeck, Scott <shollenbeck= [email protected]> wrote:
> > -----Original Message----- > > From: Taras Heichenko <[email protected]> > > Sent: Friday, November 20, 2020 6:13 AM > > To: Hollenbeck, Scott <[email protected]> > > Cc: [email protected]; [email protected] > > Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and > EPP > > > > Caution: This email originated from outside the organization. Do not > click links > > or open attachments unless you recognize the sender and know the content > > is safe. > > > > > > > On 20 Nov 2020, at 11:06, Hollenbeck, Scott > > <[email protected]> wrote: > > > > > >> -----Original Message----- > > >> From: regext <[email protected]> On Behalf Of Klaus Malorny > > >> Sent: Friday, November 20, 2020 3:47 AM > > >> To: [email protected] > > >> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses > > >> and EPP > > >> > > >> Caution: This email originated from outside the organization. Do not > > >> click links or open attachments unless you recognize the sender and > > >> know the content is safe. > > >> > > >> On 19.11.20 19:14, Gould, James wrote: > > >>> Klaus, > > >>> > > >>> The EAI support goes beyond RFC 5733 and is a perfect example of the > > >>> use > > >> of the extensibility built into EPP. Revising the RFCs and EPP > > >> extensions that use email addresses for EAI with new XML namespaces > > >> and potentially other changes is much more impactful than creating an > > >> EPP extension that specifically addresses the issue with > > >> applicability across any EPP object. I was involved with revising > > >> RFC 4310 to RFC 5910, which was needed to address significant > > >> implementation issues with RFC 4310, so I see it as a different use > > >> case. The intent is to make the EPP extension as lightweight as > > >> possible, to apply across multiple EPP objects, and to include an > > >> appropriate level of signaling (e.g., session-level, object-level, > element- > > level). Any feedback is welcome. > > >>> > > >>> Thanks, > > >>> > > >> > > >> Hi James, > > >> > > >> I chose DNSSEC as an example as I know that you took the major part > > >> in writing the update. At the very end, it is a matter of taste, and > > >> one cannot argue about. So I respect your position. > > >> > > >> As you might know, my company is developing software both for the > > >> registry side (our TANGO software) and for the registrar side (for > > >> customers and our own purpose). And for the latter, dealing with all > > >> the slightly different implementations of the EPP, within the limits > > >> of the specifications and beyond, and dealing with the flood of > > >> extensions, including different versions of them, is really anything > but > > fun. > > >> > > >> As I understand it, the original idea of EPP was to have a common > > >> protocol for all registries, and it "failed by the wayside" > > >> (hopefully the right idiom). It is not about blaming anyone for this, > > >> maybe the idea was just too ambitious. So IMHO with every proposed > > >> change to the EPP ecosystem one should ask oneself whether it > > >> increases or decreases the overall complexity and the need for case > > >> differentiation, specifically in the long run. I do not remember who > > >> said this, but there is a proverb which goes like the following: If > > >> you design a protocol, don't ask what you can add to it, but what you > can > > remove from it. While this is likely idealistic, I'll try to keep this > in my mind. > > >> > > >> Coming back to the issue, I see internationalized e-mail addresses > > >> coming to stay, like IPv6 did and IDN. So make it an integral part of > > >> the protocol, not an optional one, in the long run. But hey, that's > only my > > taste. > > > > > > Please keep in mind that they're currently an OPTIONAL SMTP extension. > I > > think that would need to change before they become a MUST for EPP. > > > > I fully agree with Klaus, the proposed extension increases the protocol > > complexity, adds a lot of job to the EPP software developers, and what it > > gives back? Less work with the RFCs? Do you really think it is a valuable > > exchange? And in a new RFC, support of non-ASCII email addresses may be > > optional. > > Sorry, but an extension is a whole lot less complex than changing the core > protocol. > >From my *implementation* experience, the extension (as a body, not just as a marker) is more complex than relaxing the email syntax. And we anyway have a much larger volume of work when the registrar starts tuning his mail system to work with EAI... -- SY, Dmitry Belyavsky
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
