Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-regext-epp-eai-10

Dmitry Belyavsky <> Sun, 05 June 2022 11:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8CBEC14F747; Sun, 5 Jun 2022 04:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id StG94Ybf7X4X; Sun, 5 Jun 2022 04:31:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id EA4A2C14F730; Sun, 5 Jun 2022 04:31:21 -0700 (PDT)
Received: by with SMTP id t25so19297494lfg.7; Sun, 05 Jun 2022 04:31:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=onNiol6tXPku6oQ8uIFz5HNmkvYTa3gAAUsN2QY0rQ0=; b=L1PQ/ZvPjPYW07cl2AzxefHOLqVBqqJmhbUc+KmltaA6zBqrac4rmo8CKL+XrtqaEl WahcG6mhYFFXj5eSeg4z/si8IgJT883RQWAdJ7aidX5O9nylJusLbo0oslIGaindFL4Y 7PAoUfFRmHq1BvTEwgQjlkhKjX4G41de0RfLGHsS/OhEJYRreAm3rvENc/sUZ1KD7bWE oExmP47xbiOrnuhU5FoHCxWBRfsC0DMt6ZUkKPw5us4x1QGTvURii3lzPnyCJv47NTCC XRe4LMAyK1DRNlSE9vRTWKdN/i09/gyqqOXpsY6nsndI4+TP3lKklYaVIzEJUxiWMyLG XpAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=onNiol6tXPku6oQ8uIFz5HNmkvYTa3gAAUsN2QY0rQ0=; b=GjSpsnw65RhTkRykzKp0YrnLyuGQaov9NhkwAR/+S+umMAwbNbxHo+gxIQmw+r6cg5 1pag8uVsuVz5keS+x4YmMNPF+LwPIAorceSItTNaN5HBc7nBai/AwCoY27ykn0zREvT4 8nl0NlzJ4HRbc0zaLnJ4Q+a3Kra/wK6ITCUfVHe1xIZEmpLSu9tm2wjYGnd3WITJZxqH q+VzgreU3sC1IVoTeUgmyzL7D4v1vy0znv6rjf2CfQF1zb7KC/DTSIMH4b02+/LVe9uX mQV41gIVwT4paOorGYjI3v8oGme4qKlvSBFDyTNfbZN/T3l4xkIbdP8WIqC+9+1/7ffS vq6w==
X-Gm-Message-State: AOAM5309WHthF5Jaj6fKmA343IKFG3wL/mqWYOWcSE+XysSaVWcxVERn EfNfeExl/QfuNlZAHyIBYPnUSUzfEuyP0jI5Vgo=
X-Google-Smtp-Source: ABdhPJyih5NnLCIU7vzYeAG9UtVejL9nV1bZaNgFBJBgy5ixef++bvy5oBMO6xhgnama4I9RBMWFXPBkVUX9zL6BFqM=
X-Received: by 2002:a05:6512:4024:b0:477:b981:de5f with SMTP id br36-20020a056512402400b00477b981de5fmr12577286lfb.350.1654428679708; Sun, 05 Jun 2022 04:31:19 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <71B4B28036B5BE0E80796F67@PSB>
In-Reply-To: <71B4B28036B5BE0E80796F67@PSB>
From: Dmitry Belyavsky <>
Date: Sun, 05 Jun 2022 13:31:06 +0200
Message-ID: <>
To: John C Klensin <>
Cc: "Gould, James" <>,, Yoshiro Yoneya <>,,,,, regext <>
Content-Type: multipart/alternative; boundary="000000000000c2a25905e0b1b1f2"
Archived-At: <>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-regext-epp-eai-10
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Jun 2022 11:31:24 -0000

Dear John,

First, please apologize me for not participating in the original discussion

On Thu, Jun 2, 2022 at 9:06 AM John C Klensin <> wrote:

> Pete and James,
> Let me add one thing to Pete's (and Yoshiro Yoneya's)
> comments/concerns.  I tried to raise this earlier, but obviously
> did not explain it well:
> --On Wednesday, June 1, 2022 20:23 +0000 "Gould, James"
> <> wrote:
> > Pete,
> >
> > Thanks for the review and feedback.  My responses are embedded
> > below prefixed with "JG - ".
> >...
> > On 6/1/22, 1:14 PM, "Pete Resnick via Datatracker"
> > <> wrote:
> >...
> >     Reviewer: Pete Resnick
> >     Review result: On the Right Track
> >
> >...
> >     Document: draft-ietf-regext-epp-eai-10
> >     Reviewer: Pete Resnick
> >     Review Date: 2022-06-01
> >     IETF LC End Date: 2022-06-09
> >     IESG Telechat date: Not scheduled for a telechat
> >
> >     Summary:
> >
> >     I think this proposal is reasonable, but I don't think
> > enough explanation has     been given regarding the case where
> > one side supports the protocol but the other side doesn't.
> Unless I don't understand the use cases for the information
> being handled by EPP and this proposed extension, there are
> actually three "sides" / "parties" for the data and their use.
> One is the registrar or equivalent, in software normally the EPP
> client.  The second is the registry or equivalent, in software
> normally the EPP server.  If those were the only two actors, one
> could be quite relaxed about the server being ready to handle
> non-ASCII email addresses because the decision to accept
> non-ASCII email addresses or not could be a contractual matter.
> >From a contractual perspective, a registrar/client who sent a
> non-ASCII contact address to a registry/server who would nor or
> could not accept such things would be a much worse problem that
> questions of how the protocol dealt with that behavior.
> However, in many, probably most, registry arrangements, there is
> also a requirement for registry databases that contain, among
> other things, contact information for registrants, etc.  While
> circumstances and regulations may impose conditions for third
> parties to access those data, such access must always be
> possible.  That is probably the important case for alternate
> ASCII addresses.  Not only are those third parties typically not
> part of the EPP transaction itself, but the registry faces the
> same issues that motivated the EAI WG to generate RFC 6857 and
> 6858: it cannot know, at the time information is placed in the
> database, what the capabilities of those authorized to access
> the data later will be.

I agree. We have government regulations and ICANN rules for these cases.
But all these requirements are out of scope of this document.
I agree that it puts an extra burden on the 3rd parties - but the
relationship between registry data and 3rd parties are definitely beyond
the IETF scope.

> Against that backdrop...
> >     Major issues:
> >
> >     The last bullet item in section 5.3.2 talks about
> > "alternative ASCII address",     but I don't see anywhere in
> > the document which defines how to provide an     alternative
> > ASCII address in the data. For example, RFC 5733 implies that
> > there     will be only one email address in the Contact
> > Mapping; can an implementation     simply add a second? Does
> > the server then need to distinguish these by the     presence
> > or absence of non-ASCII characters to determine which is an
> > EAI and     which is an alternative ASCII address? At the very
> > least, some discussion of     this seems necessary in the
> > document.
> >
> > JG - The reference to the "alternative ASCII email address" is
> > for the client (registrar) when it's recognized that the
> > server does not support EAI.  If the registrar collected an
> > EAI address and an ASCII address, then the ASCII address MUST
> > be provided; otherwise, the optional property SHOULD be
> > omitted.  The use of an ASCII proxy email address can be used
> > as well.  In this case, the server does not support EAI
> > addresses, so it's up to the EAI-supporting client to handle
> > it.  Most likely the server validates that the address is only
> > an ASCII address, but there is no guarantee of it.
> While I understand you are speaking informally here, to increase
> the odds that the text will be correct, please note that there
> are no such things as "supporting EAI" or "EAI addresses".  EAI
> is simply the name/acronym for the working group that produced a
> set of specifications.  Those specifications indicate that, if
> you are looking for a generic term, you should use the name of
> the SMTP extension, i.e., "SMTPUTF8".
> Now, when I read the above paragraph in the context of those
> registry databases and third parties accessing them (and assume
> that, when you wrote "EAI", you meant "addresses with non-ASCII
> local parts" or "SMTPUTF8").  Those EAI WG-developed specs,
> reinforced by operational experience since they were developed,
> make it very clear that, unless it is known that those who will
> be using --not just transferring-- the addresses are able to
> handle and utilize email addresses with non-ASCII local parts,
> that either there must be a reliable way to obtain an all-ASCII
> alternate address or not being able to use the contact address
> much be acceptable.  Absent a directory structure somewhere that
> records addresses with non-ASCII local parts and the all-ASCII
> fallbacks for each -- a directory that, in a registry type of
> environment, would need to be populated somehow, presumably by
> EPP -- the only reliable way to have those all-ASCII addresses
> available is to provide for (and probably require) them in the
> EPP extension and store them in the registry database.   And,
> unlike the situation contemplated by RFC 6858, registry
> databases are typically required to contain contact information
> that is both usable and accurate, more or less eliminating the
> option of simply recording an address that cannot be used.

In normal situations registries don't use its database for contacts with
domain administrators.
If a registry supports non-ASCII email addresses in EPP, it should also
support it in case of emergency contact.
But again, it's out of scope of registry-registrar protocol (EPP)

> So, coming back to your paragraph, one of my concerns (and I
> think at least part of Pete's) is that, if one option is "the
> use of an ASCII proxy email address", then you need to spell out
> where that address is going to come from.  Or, if the registry
> cannot guarantee that anyone who might legitimately have access
> to the registry database will be able to properly process and
> use contact information that contains email addresses that
> require SMTPUTF8, they must insist on being given all-ASCII
> addresses (presumably starting by insisting that the registrar
> collect them).  That, in turn, would make this extension very
> nearly useless except, perhaps, for a subset of ccTLDs who could
> impose just that requirement as a condition of legitimate
> access.
> In addition, you say
>         "If the registrar collected an EAI address and an ASCII
>         address, then the ASCII address MUST be provided;
>         otherwise, the optional property SHOULD be omitted."
> I don't know what that sentence means.  This extension does not
> appear to allow the registrar/client to transmit two addresses
> over EPP to the registry.  So, if an all-ASCII address MUST be
> provided, it is the only one and then there is no need for the
> extension (at least as I read the spec).   If the "optional
> property" is not used for all-ASCII addresses, then is then, at
> best meaningless and I don't understand the SHOULD".  The same
> situation would apply if the registrar collected only an ASCII
> address: the SHOULD does not appear to make sense.  And, if the
> registrar collected only an SMTPUTF8 address, then the only way
> to transmit it is using this optional property.
> >...
> >     Minor issues:
> >
> >     In the bullets in section 5.3.2, there are quite a few
> > SHOULDs with no     explanation of why one might choose to
> > violate these. Why are these not MUSTs?     I can't think of
> > any reason, for example, that the server would not validate
> > the email property, and it seems like a really bad idea not to.
> >
> > JG - I cover each of the SHOULDs below:
> >
> > 1. For the required email property with a client that doesn't
> > signal support for EAI, the server needs to satisfy the
> > negotiated services . This should be a MUST to comply with the
> > negotiated namespaces, since the downside is that the client
> > will receive an error response with an info command if they
> > still don't support EAI in the login services.   The error
> > response is a MUST in the third bullet.
> > 2. For the optional
> > email property falls the same case as the required email
> > property, since the info response will result in an error.  It
> > should be a MUST as well.  The error response is a MUST in the
> > fourth bullet.
> It seems to me that what you just said is that the "SHOULD"s
> were in error and that they really should have been "MUST"s.  If
> that is the case, the affected bullet points would, at least, be
> much more clear.
> I replaced these SHOULDs with MUSTs.

> >...
> >     Section 3: Change "By applying the syntax rules of
> > [RFC5322]" to "By applying     the syntax rules of [RFC6532]"
> >
> > JG - I'll leave this one for Dmitry to respond to, but
> > changing RFC5322 to RFC6532 looks correct to me.
> FWIW, note that issue was raised in my Last Call comments on May
> 26 [1] and, so far, not responded to.  If you (and that should
> mean with approval of the WG, not just you and/or Dmitry) are
> not going to change it, some explanation would be, at least IMO,
> appropriate.
> thanks,
>     john
> [1]
> <
> >
Thank you, I picked this change and it will appear in next version of the

SY, Dmitry Belyavsky