Re: [art] [Last-Call] Artart last call review of draft-ietf-regext-epp-eai-12

[Dmitry Belyavsky <[e-mail]>]

Dear John,
Thank you for raising these questions!

On Sat, Jun 11, 2022 at 7:17 AM John C Klensin <[e-mail]> 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, have recommended
> that the specification make explicit provision for carrying both
> an SMTPUFTF8 (non-ASCII in the local-part) and all-ASCII
> address.  Others, including Takahiro's review below, have asked
> that you be explicit about where alternative ASCII addresses are
> to come from.
>
> That raises three questions:
>
> Part of the problem may be in our understanding of the role of
> Section 5.3.2: to be simplistic about this, if unextended EPP
> cites RFC 5322 and therefore requires all-ASCII addresses, then
> it would seem that either client or server does not accept
> ("negotiate") this extension then non-ASCII addresses MUST NOT
> be used and the (IMO, rather confusing) language of 5.3.2 does
> not belong in this spec unless there is WG and IETF consensus to
> change RFC 5730/STD69 to require that all EPP implementations
> recognize and support SMTPUTF8 addresses in some way.
>
> So my first question is "what am I, and apparently others,
> missing here?"
>

In the upcoming version of the draft I removed the passage about
alternative email address replacing it with
"The provided address can be an extra ASCII email address collected by
registrar or registrar-provided proxy email address."
I hope this redaction of the sentence is clearer than previous ones.


>
> Then, referring to the availability of non-ASCII addresses more
> generally, if I correctly understood him, James has said that
> registries that agree to accept non-ASCII addresses will not
> need alternative ASCII ones and that, while this might cause
> problems for parties other than the EPP client (typically
> associated with a registrar) and the EPP server (typically
> associated with a registry), that issue is out of scope for this
> spec (i.e., is an unspecified Someone Else's Problem).


I agree with James that it is out of scope of this document.
But, speaking about "something else problem", I can partially agree and
partially disagree.

For example, when ICANN ran its New gTLD program, there was a question of
data escrow.
The prescribed format of the data escrow (in fact, contact database) was
specified via an IETF draft.
So this document and others are to be updated (by IETF), but ICANN-provided
obligations related to restoring data, contingency plan etc are definitely
should be updated by ICANN.

Second question: Do you agree with the assertion that such
> issues should not be addressed in the spec?  If so, what is the
> "alternate ASCII address" text all about?  If not, I don't see
> how a revision to the I-D after Last Call has ended can be
> treated as an editorial issue rather than a substantive one
> requiring community review?  Both questions are independent of
> the more fundamental one of whether there is IETF consensus for
> approving a specification on standards track that is almost
> certain to cause problems elsewhere in the relevant systems.
>

We have an ecosystem grown around RFC-822-style email addresses.
We can't replace it even on the specification level in a moment, we have to
do it step by step.

IETF regularly approves new specifications causing interoperability issues
and, beyond the reasonable efforts to remove such incompatibilities when
possible, fallbacks to legacy look the only way to move forward.


>
> Third question: These appear to me to be substantive and
> significant issues (this review's characterization of it as a
> "minor issue" notwithstanding).  Have you and/or James discussed
> the issue with the WG.  If so, and which of these positions and
> possible alterations represent WG consensus rather than
> agreement (or not) between you and your co-author?  If they had
> not been discussed with the WG, why are you revising the
> document at this point rather than withdrawing it from the Last
> Call and review processes?
>

Sorry, but I don't see any changes to the documents other than
clarification/rewording without any significant alterations of the document.


> thanks,
>    john
>
>
> --On Friday, June 10, 2022 21:49 +0200 Dmitry Belyavsky
> <[e-mail]> wrote:
>
> > Dear Takahiro,
> >
> > Many thanks for your review!
> >
> > I will update the draft in the middle of the next week
> > according to your guidelines (with Marc's amendment)
> >
> > On Thu, Jun 9, 2022 at 10:32 PM Takahiro Nemoto via
> > Datatracker < [e-mail]> wrote:
> >
> >> Reviewer: Takahiro Nemoto
> >> Review result: Ready with Issues
> >>
> >> I am the assigned ART-ART reviewer for this draft.
> >>
> >> Summary:
> >> I think this document is concise and generally good, but a
> >> few things are not
> >> explained well enough. Please consider revising the following
> >> points.
> >>
> >> Minor issues:
> >> - It is unclear how to provide "alternative ASCII addresses"
> >> in Section 5.3.2
> >> and how to distinguish between an EAI address and an
> >> alternative ASCII address,
> >> so it would be better to add an explanation.
> >>
> >> - It is unclear how to verify the code points of domain names
> >> in Section 8, so
> >> it would be better to add an explanation. RFC5892 describes
> >> how to determine
> >> the code points that can be used in IDNA2008 but does not
> >> describe how to validate domain name code points. So it would
> >> be easier to convey the intention
> >> to the reader to write "validate whether the domain name
> >> consists of the code
> >> points allowed by IDNA2008" rather than just writing
> >> "validate all code points
> >> in the domain name according to IDNA2008". Also, if the
> >> validation described in
> >> this section is intended to be compared to the code points
> >> listed in Appendix
> >> B.1. of RFC 5892, it would be better to refer to IDNA Rules
> >> and Derived Property Values
> >> <
> >> https://www.iana.org/assignments/idna-tables-12.0.0/idna-tabl
> >> es-12.0.0.xhtml
> >> >
> >> listing the latest IDNA Derived Property Values.
> >>
> >>
>
>
>

-- 
SY, Dmitry Belyavsky