Dear colleagues,
We've updated the document according to SECDIR and ARTART reviews.
-- Forwarded message -
From:
Date: Wed, Jun 15, 2022 at 10:03 PM
Subject: [regext] I-D Action: draft-ietf-regext-epp-eai-13.txt
To:
Cc:
A New Internet-Draft is available from the on-line
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the
IETF.
Title : Use of Internationalized Email Addresses in the
Extensible Provisioning Protocol (EPP)
Authors
Dear John,
Thank you for raising these questions!
On Sat, Jun 11, 2022 at 7:17 AM John C Klensin wrote:
> Dmitry,
>
> My recollection is that, in one way or another, every review has
> mentioned the issue of alternate ASCII addresses and SMTPUTF8
> ("EAI") addresses. Some, including myself,
Hi.
Agree with Scott that we first fix the errata per the original intent of the
authors, in order to have the STD 95 docs in a clearer state for the current
approach (approach A).
Once that's out of the way, we can discuss the merits of the current approach
(approach A) versus the 2 newly
Jim, I didn't say that "lunarNIC_level_0" isn't supported. What I *am* saying
is that both authors of the document agree that the existing text contains an
editorial error that should be fixed such that the two sections of 9083 are
consistent. We could just as easily change all instances of
Scott,
I believe the first step is to come to consensus on the desired extension
registry approach or approaches. I personally like the use of
"lunarNIC_level_0" in the rdapConformance to ensure that versioning of the
specification is fully supported. Approach B could be used to allow for
Thanks for doing all this work, Jasdip. Now we have to decide what to do with
all of this information.
As a first step, I think we need to submit errata to address issues with the
existing RFC(s). RFC 9083 uses both "lunarNIC" and "lunarNIC_level_0". At a
minimum, Andy and I agree that
