Dear John,
Thank you for raising these questions!On Sat, Jun 11, 2022 at 7:17 AM John C Klensin <john-ietf@xxxxxxx> 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
<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.
>>
>>
SY, Dmitry Belyavsky
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
