> On 20 Nov 2020, at 11:06, Hollenbeck, Scott
> <shollenbeck=40verisign....@dmarc.ietf.org> wrote:
>
>> -----Original Message-----
>> From: regext <regext-boun...@ietf.org> On Behalf Of Klaus Malorny
>> Sent: Friday, November 20, 2020 3:47 AM
>> To: regext@ietf.org
>> 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.
>
> Scott
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
--
Taras Heichenko
ta...@academ.kiev.ua
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
