[Last-Call] Re: Last Call: <draft-ietf-regext-epp-eai-23.txt> (Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




--On Thursday, February 6, 2025 16:01 +0000 "Hollenbeck, Scott"
<shollenbeck@xxxxxxxxxxxx> wrote:

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

As long as it is explicit -- the apparent ambiguities are my main
concern.

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

Again, as long as the requirement is explicit -- and somehow
consistent with what you say about <contact:disclose> as above -- I
can live with it.
 
>> (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.

Wfm.

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

And, again, my concern is about apparent ambiguities about what the
spec is doing and how it might interact with additional extensions
and much less with what solutions you work out as long as they make
things clear and explicit.

thanks,
   john

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux