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 <john-ietf@xxxxxxx> 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"
<jgould=40verisign.com@xxxxxxxxxxxxxx> 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"
> <noreply@xxxxxxxx> 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) definition.
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]
<https://mailarchive.ietf.org/arch/msg/last-call/pDEjCW75nLxnd-NbNcPR3E7VKfE>
SY, Dmitry Belyavsky
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
