John, Thank you for your review and feedback. My responses are embedded below. -- JG James Gould Fellow Engineer jgould@xxxxxxxxxxxx <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@xxxxxxxxxxxx> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/26/22, 2:11 PM, "John C Klensin" <john-ietf@xxxxxxx> wrote: --On Thursday, May 26, 2022 08:59 -0700 The IESG <iesg-secretary@xxxxxxxx> 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 last-call@xxxxxxxx mailing lists > by 2022-06-09. Exceptionally, comments may be sent to > iesg@xxxxxxxx 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
