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?"
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).
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.
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?
thanks,
john
--On Friday, June 10, 2022 21:49 +0200 Dmitry Belyavsky
<beldmit@xxxxxxxxx> 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 < noreply@xxxxxxxx> 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.
>>
>>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
