Dear John,
Many thanks for your letter!See my response below.
--
On Thu, Aug 18, 2022 at 7:59 AM John C Klensin <john-ietf@xxxxxxx> wrote:
James,
Replying to this note rather that several of the others because
it most clearly identifies what is being done. I am copying, I
hope, the relevant review teams.
There are, I believe, three separate but closely-related issues
here:
(1) The document, through the -14 draft, contained some language
about an "extra" all-ASCII address when an SMTPUTF8 address was
supplied. It failed to indicate how that was to be transmitted,
what function it served, where it might appear in data
structures, etc. You now propose to solve that problem by
eliminating the discussion of such addresses, presumably because
it is strictly a registrar <-> registrant issues. That would
be fine, except...
(2) Whether we like it or not, when non-ASCII email addresses,
especially ones using scripts very different from European and
other so-called GLC-related one are used in arbitrary ways, they
don't work smoothly and globally. They are fine for, e.g.,
ccTLDs where communications, as well as domain name labels are
confined to a script or two and known providers, but not for
generalized communications or registries handling arbitrary
scripts. If the purpose of this protocol is ultimately to
populate registry databases -- databases whose contents are
expected to provide reliable contact and identify information
for registrants even if that information is only accessible
under court order or the equivalent -- then all-ASCII
alternative addresses are a necessity. It would remain a
necessity if the relevant registrar (or, for that matter, some
of its agents) goes out of business, taking any data with them
that are not part of the registry database. Provision for the
alternate names should be part of the protocol, part of the data
structure, and part of the databases. There may be cases where
they are not needed, but that does not reduce the requirement to
be able to carry and process them.
(3) Or if, as I believe one of your recent notes suggested,
those alternative addresses are strictly a matter between the
registrar and registrant, that raises two other questions.
First, if a registrar is in need of the information to
adequately communicate with the registrant, why isn't the
registry and those with legitimate access to registry databases?
Second, if the information covered by this draft is strictly a
matter of data supporting business relationships -- either
registrant-registrar or even registrar-registry -- and not the
operation of the public Internet -- the document does not make
the case that it is a legitimate topic for IETF standardization
any more than elements of service contracts between ISPs and end
users would be.
I strongly consider those alternative addresses as a part of registrar business processes not affecting the EPP protocol.
Answering your sub-questions:
First, the registrar has direct obligations to the registrant (and needs more contact information).
Registry normally doesn't have direct contract to a registrant until smth urgent happens to the registrar.
Second, this draft doesn't specify any new data that differs from those currently collected by the registry.
But this collection/transfer is managed by IETF standardized protocols,
and any amendments to this protocol is definitely a legitimate topic for IETF standardization.
Also, as these data are available (at least partially, for some categories of registrants, etc)
via RDAP, it is part of operations of the public Internet.
best,
john
--On Wednesday, August 17, 2022 13:20 +0000 "Gould, James"
<jgould=40verisign.com@xxxxxxxxxxxxxx> wrote:
> Nemo,
>
> In the -15 draft, we will be removing the following two
> statements in section 5.3.2 and fix the nit "allow:ed" in
> section 8. I believe this addresses your issues. Can you
> clear your "Ready with Issues" status in the tracker?
>
> 1. Delete "It can be an extra ASCII email address collected by
> registrar or registrar-provided proxy email address." from the
> fifth bullet in section 5.3.2. 2. Delete "The provided
> address can be an extra ASCII email address collected by
> registrar or registrar-provided proxy email address." from the
> last bullet in section 5.3.2.
SY, Dmitry Belyavsky
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
