Re: [regext] [Last-Call] 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 again for your detailed review and feedback.  My responses are included below prefixed with "JG2 -" .

-- 
 
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/27/22, 12:00 PM, "John C Klensin" <[e-mail]> wrote:

    Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

    James,

    A few comments on yours below (with a lot of text elided).  Then
    I'm going to step back from this until/unless others are heard
    from.

    --On Friday, May 27, 2022 12:03 +0000 "Gould, James"
    <jgould=[e-mail]> wrote:

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

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

    >...
    >>     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.

    I note that you did not respond to the above.  Probably that is
    ok -- it could reasonably be interpreted as calling for a
    response from WG Chairs and AD, not authors.

    >>     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.  

    I think that at least partially misses the point, so let me try
    this differently.  "Extension types" are presumably important to
    EPP.  They seem to be important enough that you feel called upon
    to say "there were three and now we are adding another one".
    Perhaps more to the point, while I had not reviewed the base EPP
    document, RFC 5730/STD 69, before sending my earlier note, I
    have now.  Its section 2.7 of the lists those types and says
    "allows features to be added at the protocol, object, and
    command-response levels".  That is a very strong implication
    that those are the _only_ kinds ("levels") of features that can
    be added.  

    Internet Standards are not chiseled into stone and nothing
    prevents modifying them.  But, at least IMO, adding another
    level of features is certainly enough of a big deal to require
    explicitly updating RFC 5730 (which the I-D does not identify in
    its header).   And the WG should be providing (I'm inclined to
    say "owes") the community an explanation of why a fourth type is
    needed as well as a clear description of that type that
    parallels 2.7.1 - 2.7.3 rather than [just] the language of
    Section 4 of the I-D.   The latter appears to very nearly imply
    that the extension model of 5730 is inadequate because it does
    not provide for overlays on other extensions and properties.  If
    that is the case (I might be misreading it, but then your
    Section 4 is not clear enough), then that is an even stronger
    reason why a clear update to Section 2.7 of RFC 5730 is needed.

    Finally, perhaps you have been lucky enough to be spared the
    pain, but we've repeatedly discovered (see the IAB's efforts to
    understand protocol extensibility) that putting features into a
    protocol that are defined on the basis that no one foresees
    reasons to use them in different ways leads to complications in
    both technical specifications and the ways we construct
    documentation.

    In any event, the fact that this new type changes, indeed
    violates, a provision of RFC 5730, very strongly suggests that a
    separate document that updates it and provides adequate
    explanation is a necessity.  Even if there were consensus that
    it was not needed, this I-D would still be updating 5730 and
    should be identified as such.

JG2 - I don't agree that section 2.7 of RFC 5730 defines the only forms of extensibility that can ever be supported by EPP and by defining a new form of extensibility to solve a specific problem in EPP is disallowed or non-compliant with RFC 5730.  In this case, the form of extensibility (Functional Extension) is formerly defined in draft-ietf-regext-epp-eai for clarity for use in solving the specific problem of EAI in EPP.  The intent is not to define a new form of extensibility to EPP in RFC 5730 to solve other similar problems.  I agree if a Functional Extension is meant to be a new formal form of extensibility for use in other yet to be defined EPP extensions, then it would make sense to define it in a draft by itself, but that is not the case with draft-ietf-regext-epp-eai.

    >>     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.  

    Ok.  On this I have to defer to those who have been involved in,
    or studied, EPP more deeply than I have (or have time to do).  I
    can only say that it gives me a bad feeling and that the object
    would be much more serious were this document or any of those
    three be proposed for advancement to Internet Standard.

JG2 - I'm not clear what the issue is with providing direction on how to migrate to a new version of the extension within the draft / RFC.  A practice has been followed while creating the EPP extensions of leveraging pointed version numbers (e.g., "0.1", "0.2", "0.N") that eventually get updated to a major version (e.g., "1.0") when progressing up to an RFC, so there may be implementation that need to migrate from a pointed version to the major version.  If an update is made to the RFC that requires a change in the major version, the migration would be applicable as well in the RFC update.  There are no envisioned updates for draft-ietf-regext-epp-eai.     

    >>     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?

    AFAICT, you did not respond to that point.

JG2 - Sorry, was RFC 6531 intended in the existing EPP RFCs (e.g., RFC 5733, 8543)?  I don't believe the existing EPP RFCs envisioned support for more than a subset of ASCII characters defined in RFC 5322, which is the purpose of draft-ietf-regext-epp-eai to address.  There are additional non-RFC EPP extensions that also didn't envision support for more than a subset of ASCII characters, which is unique to EAI.  

    >>     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. 

    I can only give you my opinion.  That opinion, while informed by
    my involvement as co-chair of the EAI WG and co-author of RFC
    6530, may not represent informed community consensus today.
    The collection of specifications in RFC 6530-6532 are more than
    about syntax -- the documents (at least try to) rather carefully
    explain the potential disruptions and dangers to
    interoperability of essentially creating an incompatible overlay
    to the Internet's email systems.  The security considerations
    discussions in RFCs 6530 and 6531 that you incorporate by
    reference are only part of that story.

    If an application is going to refer to that set of
    specifications as the authority for what it is doing, then it
    has some obligation to consider the discussions in them, not
    just pick up a piece of syntax out of context, use it, and cite
    the SMTPUTF8 family of specifications as the authority.

    I don't think mentioning some risks in a Security Considerations
    section sufficiently addresses those issues, with the potential
    need for either a fallback address or a different negotiation
    design being the most important.  

    	ASIDE:  I know this is complicated.  I would apologize
    	on behalf of the EAI WG, but fault lies with whatever
    	entity or process to which one attributes the vast
    	differences in human languages and writing systems.
    	Many of our efforts, not just within the IETF, but in
    	the Unicode Consortium and elsewhere, are ultimately
    	about trying to overlay universal common principles on
    	systems that do not inherently have them.  If one wants
    	to use non-ASCII strings in protocols or as protocol
    	elements (as distinct from putting some Unicode-encoded
    	free text somewhere; even that often has issues
    	especially if the text is going to be displayed).  You
    	want strings like non-ASCII email addresses, you accept
    	the complexity.   There was even clear awareness within
    	the EAI WG that non-ASCII email addresses might be a bad
    	idea, i.e., that email addresses should be treated as
    	protocol elements.  For several of the participants, the
    	main reason for even defining such addresses was that
    	people were going to do it anyway and it was more
    	important to have clear and interoperable specifications
    	than to try to stop the oncoming train (fwiw, the same
    	thing was said about non-ASCII domain name labels and,
    	due to the IDNA innovation, they were, and are, far more
    	safe).

    The second paragraph in that section of the I-D adds confusion
    rather than clarity.  If readers interpret it as a summary, they
    are discouraged from believing they actually need to open and
    study the sections of RFCs 6530 and 6531.  If they did study
    those documents, they would discover that the paragraph is fully
    covered by, and a small subset of, them.  The paragraph's focus
    on issues related to domain names ignores the risk, at least as
    serious, as attacks on local-parts. For example, in a world with
    email service providers (some of whom support non-ASCII local
    parts or will do so soon) that support millions of mailboxes at
    the same domain, a "homograph" attack on local-parts is far
    easier (and likely to be effective sooner) than registering a
    similar but malicious domain name and waiting for a mistake to
    be made.  Not only is the set of local-parts a bigger target
    (opportunity) space, but, as 6350 points out (but the paragraph
    in the I-D does not), IDNA imposes some constraints that prevent
    a subset of possible attacks that SMTPUTF8 does not.

    If, instead, readers interpret that paragraph providing material
    in addition to what is in the cited RFCs... well, it doesn't.

    At a minimum, more clarity is needed in that section.  If your
    comment was meant to imply that is covers enough of the
    considerations to eliminate the need to careful attention to the
    provisions of the SMTPUTF8 collection of RFCs in you design, it
    is, at best, inadequate.

JG2 - Any suggested language to include is greatly appreciated.  The intent is not to duplicate language in draft-ietf-regext-epp-eai from RFCs from the EAI WG to be capable of supporting EAI in the EPP protocol.  

    best,
       john