--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.
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>
(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.
(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).
thanks,
john
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
