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"
<[email protected]> 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"
<[email protected]> 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.
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.
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.
...
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]
<https://mailarchive.ietf.org/arch/msg/last-call/pDEjCW75nLxn
d-NbNcPR3E7VKfE>
