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

[Dmitry Belyavsky <[e-mail]>]

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 <[e-mail]> 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=[e-mail]> 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"
> > <[e-mail]> 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
> >
>
>
Thank you, I picked this change and it will appear in next version of the
document

-- 
SY, Dmitry Belyavsky