> -----Original Message----- > From: John C Klensin <klensin@xxxxxxx> > Sent: Thursday, January 30, 2025 12:04 AM > To: last-call@xxxxxxxx > Cc: draft-ietf-regext-epp-eai@xxxxxxxx; jkolker@xxxxxxxxxxx; regext- > chairs@xxxxxxxx; regext@xxxxxxxx > Subject: [EXTERNAL] Re: Last Call: <draft-ietf-regext-epp-eai-23.txt> (Use of > Internationalized Email Addresses in the Extensible Provisioning Protocol > (EPP)) to Proposed Standard > > 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. > > > --On Monday, January 13, 2025 15:35 -0800 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-23.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 2025-01-27. > > Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In > > either case, please retain the beginning of the Subject line to allow > > automated sorting. > > Sorry this is late; I've been preoccupied with two other documents in or near > the IESG queue. It appears to me that none of the concerns identified below > have been addressed in any of the published reviews. > In case it is still useful... > > I was involved with, and made some suggestions about, and contributions to, > earlier versions. Compared to those versions, which had characteristics I > believed could be harmful, this one is a vast improvement. I do have some > remaining concerns about conceptual issues with this specification -- concerns > that, IIR, were shared with the authors and WG some months ago and that are > closely related to concerns raised much longer (years) ago -- but, unlike the > issues with those earlier versions, I don't believe these are likely to cause > significant harm, especially in the near future, if not addressed. > > This version is also much easier to follow so thanks to the authors and all > involved. > > Remaining issues/ concerns follow. > > (1) Binding of the alternate address to particular elements of a response. > Using Example 2 in Section 5.1.2 (because it is handy), observe that there are > two possible email address elements as part of <resData>, one associated with > <contact:email> and the second > associated with <contact:disclose><contact:email/>. The > <addlEmail:addlEmail> element, added by this extension, is not part of > <resData> but, instead, is part of a separate <extension> element. > Now this is not a problem today because > <contact:disclose><contact:email/> cannot actually include an email address > with the <contact:email> element so the only email address for which the > extension is an alternative is the one directly > subsidiary to <resData><contact>. At the very least, I think the > specification should spell that out. [SAH] Thank for the feedback, John! Good catch here! You're right, this is worth mentioning. We can add text to say that the value set for <contact:disclose><contact:email/> MUST also apply to additional email addresses that are added by a contact extension. > However, it may also be worth thinking about possible future extensions. > Suppose the EPP data structure were expanded in the future so that more > than one <email:*> field were added to <regData>, either subsidiary to > <contact:infData> or further down in that tree. > Or suppose a new element were added to <response>, at the same level as > <resData> and <extension> that had a subsidiary element with an > email address. In any of these scenarios, there would be a question > about which email address the one specified with <addlEmail:addlEmail> was > an addition/ substitute for. It seems to me that it would be wise to modify this > specification in at least one of the following ways: > > (i) Explain the implications of this design for further extensions. > If there is any possibility that we are digging ourselves into a hole, let's at least > describe what that hole looks like. > > (ii) Provide for an additional subelement of <addlEmail:addlEmail>, or an > additional argument for that element definition, that would somehow identify > exactly what element the additional address modifies or supplements. > > (iii) Do the obvious, even if it requires tweaking definitions in the > base EPP specs themselves. That obvious measure would be to define > <addlEmail:addlEmail>, not as a subelement of <extension>, but as a > potential optional element of any <*:email> element. Using the same > example, one might then have > <contact:email>jdoe@xxxxxxxxxxx > <addlEmail:addlEmail > xmlns:addlEmail="urn:ietf:params:xml:ns:epp:addlEmail-1.0"> > <addlEmail:email>jdoe-alt@xxxxxxxxxxx</addlEmail:email> > </addlEmail:addlEmail> > </contact:email> [SAH] My preference is (i), noting that any address included in an extension is intended to be an additional address that's associated only with the primary <contact:email> address, and that support for any other additional email addresses MUST explicitly describe how the additional addresses are associated with the existing addresses. > (2) Using this extension as a general mechanism for adding a secondary or > backup email address, rather than something specific to non-ASCII addresses, > is inconsistent with the title of the document and probably argues for some > revision to the Abstract and the first paragraph of the Introduction rather than > writing the document as, approximately, "this is about non-ASCII email > addresses, but can be > about all-ASCII ones too". A title closer to "Use of Alternate > Email Addresses, Including Internationalized Ones, in the Extensible > Provisioning Protocol (EPP)" would more accurately reflect what is going on. > Probably someone can come up with a shorter variation. [SAH] Another good catch. I'm fine with your suggestion above, or perhaps "Additional Email Address Extension for the Extensible Provisioning Protocol (EPP)" with appropriate changes to the abstract and introduction to note that both internationalized and all-ASCII addresses are included. > (3) Treating the additional address as something that can be either all-ASCII or > one that requires SMTPUTF8 handling opens up the question of whether, if > the primary email address (as specified in > <resData><contact:infData><contact:email>) requires an alternative, what is to > prevent the alterative (all-ASCII or not) from requiring an alternative? That > question presumably has a satisfactory answer, but I believe it should be > addressed and answered in the document (and, as with the above, with some > care about possible future extensions of time shows the answer to be > inadequate). [SAH] Yes, we can add text to make it clear that this extension supports the addition of only one additional address, and (as noted above) that extension support for any other additional email addresses MUST explicitly describe how the additional addresses are associated with the existing addresses. Scott -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
