Re: [regext] Last Call: <draft-ietf-regext-epp-eai-10.txt> (Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)) to Proposed Standard

["Gould, James" <[e-mail]>]

John,

Thank you for your review and feedback.  My responses are embedded below.  

-- 
 
JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 5/26/22, 2:11 PM, "John C Klensin" <[e-mail]> wrote:



    --On Thursday, May 26, 2022 08:59 -0700 The IESG
    <[e-mail]> wrote:

    > 
    > The IESG has received a request from the Registration
    > Protocols Extensions WG (regext) to consider the following
    > document: - 'Use of Internationalized Email Addresses in the
    > Extensible
    >    Provisioning Protocol (EPP)'
    >   <draft-ietf-regext-epp-eai-10.txt> as Proposed Standard
    > 
    > The IESG plans to make a decision in the next few weeks, and
    > solicits final comments on this action. Please send
    > substantive comments to the [e-mail] mailing lists
    > by 2022-06-09. Exceptionally, comments may be sent to
    > [e-mail] instead. In either case, please retain the
    > beginning of the Subject line to allow automated sorting.
    > 
    > Abstract
    > 
    > 
    >    This document describes an EPP extension that permits usage
    > of    Internationalized Email Addresses in the EPP protocol
    > and specifies    the terms when it can be used by EPP clients
    > and servers.  The    Extensible Provisioning Protocol (EPP),
    > being developed before    appearing the standards for
    > Internationalized Email Addresses (EAI),    does not support
    > such email addresses.

    Hi.

    Several comments after a first and quick look through this
    document.

    First, it appears that it is making a more fundamental change to
    EPP than just allowing for SMTPUTF8 (aka "non-ASCII" or "EAI")
    addresses local parts.  The second paragraph of the Introduction
    says
    	 "A new form of EPP extension, referred to as a
    	Functional Extension, is defined and used..."
    and Section 4 defines that mechanism.   Because there are people
    who might look at an announcement of Last Call for an
    internationalization-related extension and say either "someone
    else will look at those complexities" or "oh, sure, non-ASCII
    addresses are good", and move on, introduction of that new type
    of extension should be highlighted in the Abstract and should
    have been included in the Last Call so as to draw attention from
    those who are, e.g., concerned about the tradeoffs associated
    with adding complexity to EPP.

    It would be helpful to have assurances that the WG carefully
    considered the idea and definition of a new extension type and
    any associated tradeoffs independent of the particular
    requirements of this document.  While it might be necessary,
    complexity and added options do not promote interoperability.
    It would also be helpful to know whether developing a separate,
    short, document defining the new extension type so it could
    conveniently be referenced from this document and other
    specifications had been considered.  Especially if an update or
    replacement for this document is anticipated, referencing it
    from other extensions that use the new type invites the tangled
    problems of whether such a reference to an obsolete or updated
    document is still appropriate.

JG - Support for EAI across a set of existing and future EPP extensions did represent a new extensibility use case was discussed in the working group, along with other options.   The intent of the draft is to support EAI with the definition of a functional extension being as a building block to satisfy the requirement.  If the use of a functional extension is needed beyond EAI then I agree that a functional extension draft can be created.  I don't foresee that need at this point.  


    Second, Section 2, titled "Migrating to Newer Versions of This
    Extension" strongly implies that a different form of this
    extension, or a different extension mechanism serving the same
    purpose is under development (or even further along) and
    expected to succeed this one.  If that is the case, should this
    specification not be published as Experimental rather than
    Standards Track (or even, noting Section 7, as "Verisign's
    Preliminary Mechanism for Use of Internationalized Email
    Addresses in..." and Informational)?  Or, if there is a
    substantive reason to publish as Standards Track, I believe the
    document should explain the reasons for doing this now when an
    update/replacement using a different mechanism is anticipated?
    Version numbers or not, the way of doing things that seems to be
    proposed in the document also does not appear to be a good way
    to promote interoperability.

JG - The migrating to new versions section has become common in the EPP extensions (e.g., Section 2 of RFC 9167, Section 2 of RFC 8807, Section 2 of RFC 8748).  The draft is solely focused on supporting EAI in EPP that used pointed version numbers (e.g., urn:ietf:params:xml.ns:epp:eai-0.1, urn:ietf:params:xml.ns:epp:eai-0.2,  urn:ietf:params:xml.ns:epp:eai-0.3) for draft implementation signaling until after WGLC when the version was changed to urn:ietf:params:xml.ns:epp:eai-1.0.  This section is needed to provide guidance as implementations upgrade to version urn:ietf:params:xml.ns:epp:eai-1.0.  The standards track is appropriate for the draft.  The work is complete and there is no mechanism serving the same purpose under development.  

    Third, with regard to the i18n parts of this:

    Nit: The last sentence of Section 3, 
    	"By applying the syntax rules of [RFC5322], the EPP
    	extensions will change from supporting only ASCII
    	characters to supporting Internationalized characters
    	both in the email address local-part and domain-part."
    Does not appear to make sense since, as pointed out earlier in
    that section, the syntax rules of RFC 5322 only allow (a subset
    of) ASCII characters.  Was "[RFC6531]" intended?

    While the SMTPUTF8 extension is now supported in most popular
    sender-SMTP ("client") and receiver-SMTP ("server")
    implementations, comprehensive support in MUAs and other
    relevant, user-facing, programs and user interface arrangements
    (including support by humans) is less common (where
    "comprehensive" includes all scripts and all languages).  This
    document shows no evidence that the WG has considered whether it
    would be appropriate and should be possible to negotiate script
    or language-specific use.  While that probably has nothing to do
    with the technical use of the EPP protocol (i.e., computers
    talking with computers), it could be very important to practical
    operational use.  If nothing else, the document should probably
    containing appropriate warnings to registrars and/or registries
    who, for whatever reason, would like to claim better support for
    those working in languages other than English about possible
    pitfalls.

    Similarly, at least because the server-end downgrade mechanisms
    described in RFC 6857 do not appear to be widely supported and
    those described in RFC 6858 lose information, it would appear to
    be useful for this extension to include provisions for an
    all-ASCII, RFC 5321/5322-conforming, fallback or alternate
    contact address.  I see no way to provide such an address in
    this spec.

    There might be other issues as well, but I would strongly
    encourage the WG to think about the entire system surrounding
    this protocol extension, including not only EPP clients and
    servers but registrants and those third parties who legally and
    appropriately access registry (and, if separate, registrant)
    databases to access, understand, and use information.  For
    example, nothing in RFC 6530 and the related documents prohibits
    the use of obscure and archaic scripts as local-part strings
    but, especially when there are bidi rendering issues involved,
    such strings can be very difficult to understand, use, or even
    copy into other contexts.

JG - The challenge in the draft is how to apply the non-ASCII email address syntax defined in RFC 6530 to the EPP protocol, which is highlighted in section 3 of the draft.  The focus is on the EPP protocol and not non-protocol policy elements.  The security considerations section highlights risks that need to be considered.   

    Disclaimer: These comments are those of the author only and
    should not be confused with an i18ndir review.  Neither they nor
    the document have been discussed on that list.

        john