John, Thank you again for your detailed review and feedback. My responses are included below prefixed with "JG2 -" .
-- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/27/22, 12:00 PM, "John C Klensin" <[email protected]> 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" <[email protected]> wrote: > John, > > Thank you for your review and feedback. My responses are > embedded below. >... >> On 5/26/22, 2:11 PM, "John C Klensin" <[email protected]> >> 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 _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
