Are there any concerns if we post draft-ietf-regext-epp-eai-19 as proposed below, which is to revert to draft-ietf-regext-epp-eai-17 with the support for one or two email addresses using either ASCII or SMTPUTF8, remove any reference to the requirement for an ASCII email address, and remove the concept of a transition period? This will leave the decision related to what combination of e-mail addresses to support to server policy. If there are no concerns, Dmitry and I will post draft-ietf-regext-epp-eai-19 as proposed.
Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of "Gould, James" <jgould=40verisign....@dmarc.ietf.org> Date: Friday, August 18, 2023 at 3:06 PM To: "gal...@elistx.com" <gal...@elistx.com> Cc: "beld...@gmail.com" <beld...@gmail.com>, "a...@gulbrandsen.priv.no" <a...@gulbrandsen.priv.no>, "a...@hxr.us" <a...@hxr.us>, "Hollenbeck, Scott" <shollenb...@verisign.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Proposed update to draft-ietf-regext-epp-eai Jim, I believe defining functional equivalence between an ASCII and SMPTUTF8 address is policy and not protocol. EPP is a provisioning protocol that enables a client (registrar) to create and update email addresses in a server (registry), where the protocol simply needs to be capable of passing either ASCII or SMPTUTF8 addresses. If a server defines a policy that requires an alternative address (ASCII, SMPTUTF8, or either one), then they can do so using the extension that supports the policy in the protocol. My desire is to keep this simple and not venture into the policy pandora’s box. My proposal is to roll things back to draft-ietf-regext-epp-eai-17, remove any reference to the requirement for an ASCII email address, and remove the concept of a transition period. Leave the decision up to server policy what combination of email addresses to allow. -- JG [cid:image002.png@01D9F54A.03E7FAE0] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/1O7iX9JburqYIM3uWPUYi903XOsYrefYURbXu2RkXNI4lB4GTO8jfjA7f4P-fhWjIgxIoiBPYgVpIt4V5sK-zd3-1YmkmtqbYwesKND4gJL_G0O6SXj7VrxUZS30WazpfBilNWCX0M-KpqUTXQnSSvr29qzqLrezUCLcSrDPBq8FMAcpjWYEwM_q-DpXxEGCSUWceN8mLKNeCUIysayuzNUK5LmxWM_TnylVxHg2gBS9bL_jEIayhZjgrZpj_9AnWhB8ulshMn5-2BhVPF5ohCnYFLkXLKirlMI7v0Z-Mh1I/http%3A%2F%2Fverisigninc.com%2F> From: James Galvin <gal...@elistx.com> Date: Friday, August 18, 2023 at 2:50 PM To: James Gould <jgo...@verisign.com> Cc: "beld...@gmail.com" <beld...@gmail.com>, "a...@gulbrandsen.priv.no" <a...@gulbrandsen.priv.no>, "a...@hxr.us" <a...@hxr.us>, "Hollenbeck, Scott" <shollenb...@verisign.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Proposed update to draft-ietf-regext-epp-eai 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. I’m not following Jim. My proposal is simply to state what it means in the protocol when an internationalized email address extension is present. My proposal is not to say when an internationalized email address extension is required. Stating the presumption of functional equivalence is making it clear we are not changing the semantics of EPP, i.e., we are precisely not opening the discussion of policy. To frame this more concretely, a contact object semantically in EPP has a single email address, and even if syntactically two are present they are semantically the same thing. Please help me understand how this is a policy statement? Jim On 18 Aug 2023, at 14:39, Gould, James wrote: Jim, This moves the protocol too far into policy. Let policy define when an ASCII email is needed. Based on the back-and-forth with this draft, I believe it’s best just to add support for an extra e-mail address field, where both the existing and the additional email can be either an ASCII or an SMTPUTF8 address that is up to server policy. Any other rules spelled out in the draft is policy that is out of scope for the protocol. The fact that we can’t come to agreement on whether there must be an ASCII email address eternally, there must be an ASCII email address during a transition period, or an ASCII email address is optional provides the indication that we are defining policy and not protocol. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://secure-web.cisco.com/10E4pdFvTWXr-l5LSpYaOS8y4jkuRuQD4wH2QMAu7ds3TqWTm2awiK113fn7is6KYhkyzTw_khPRXel8CYCrjlU2_Sn4x-XVPmfE4N6luk5Dn5G8BKtIU5xJ5UJyGN2Ruw2EvI3nYxWNplYC9aQRRyqdKiD1n46HsEahbhC6WAI44WfKUcWJaHH0jRGPK-NREM73lGKXj7dNDMH5JL2lUvWMtac3WQHtSU06xsqqKWp_cU-elKjEHbnARmDdjLaP_dc7gXKUEet8yxVBJVDRZxm4d4gYwlp7U6Rhi08YgpIw/http%3A%2F%2Fverisigninc.com%2F> From: James Galvin <gal...@elistx.com> Date: Friday, August 18, 2023 at 2:27 PM To: Dmitry Belyavsky <beld...@gmail.com> Cc: Arnt Gulbrandsen <a...@gulbrandsen.priv.no>, Andrew Newton <a...@hxr.us>, James Gould <jgo...@verisign.com>, "Hollenbeck, Scott" <shollenb...@verisign.com>, regext <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Proposed update to draft-ietf-regext-epp-eai My understanding of this thread so far is that the consensus is moving towards allowing for the collection of two email addresses. I very much support this position. One question I don’t believe we have answered carefully is what it means to have both email addresses present or just the internationalized email address present. I have a suggestion to consider. First, I would propose that the specification state if an internationalized email address is present it is required and presumed to be functionally equivalent to the baseline email address (whether it is present or not). Whether or not this requirement can be validated is outside the scope of this specification. The extension may be present for (subordinate to?) to any existing email address element. What this gets us is that we don’t have to say what that functionality is precisely. Whatever context in which the EPP protocol is being used has a defined purpose for the presence of an email address. All this extension has to say is that whatever the purpose (functional requirement) of an email address is, either email address is presumed to serve that purpose. With that, I think the 4 possible cases are pretty straightforward to explain. 1. only US-ASCII present - this is covered by the base spec so nothing to add here. 2. extension present with a value, no value in the US-ASCII element - this is also covered by the base spec since the value present is just treated exactly as an email address, just with an expanded syntax. The value can be provided to any client whenever an email address is requested because clients SHOULD ignore any extension they do not understand. 3. both US-ASCII present and extension present with a value - in this case the email addresses are presumed to be functionally equivalent, the syntax of each is validated, both are stored by the server, and both are always provided whenever an email address is included in a response. This works because clients can ignore the extension if they don’t understand it. 4. extension present with no value - at the protocol level this should be ignored. That is my suggestion. The critical point there is the protocol presumes functional equivalence. Conceptually, we are sticking to the model of a single email address and simply expanding the syntax. Some day, if we ever seek to update or replace EPP we might do this entirely differently. However, this gets us what we need within the model that we have. Jim On 8 Aug 2023, at 16:03, Dmitry Belyavsky wrote: Dear Arnt, On Sun, 6 Aug 2023, 13:39 Arnt Gulbrandsen, <a...@gulbrandsen.priv.no<mailto:a...@gulbrandsen.priv.no>> wrote: Thursday, 3 August 2023 20:14:41 CEST writes: > On Thu, Aug 3, 2023 at 1:23 PM Gould, James > <jgo...@verisign.com<mailto:jgo...@verisign.com>> wrote: >> >> So, rollback to draft-ietf-regext-epp-eai-17 with the concept >> of a transition period removed and inclusion of "at least one >> of the email values MUST be an ASCII address"? > > Doesn't that put us back to requiring two email addresses to support EAI? > > I was thinking that "if more than one email value is provided, one > MUST be an ASCII address". Therefore the options are: > 1) provide an ASCII email address. > 2) provide an SMTPUTF8 email address. > 3) provide both There is, of course, the possibility of a hack... "At least one of the contact addresses MUST be an ASCII address. This restriction may be lifted in a future revision of this document." > The draft will still need text such as provided by Arnt to justify option 2. > > And I agree with removing the transition period. I'll be happy to provide suitable text. Massaging what I wrote to fit the context. It would be great, many thanks in advance! _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1WfMMXQOXS-HGPcqBSIUSFjHvLt2RRjVXnkc8B18xnu9uEBmBl7Fho6AuLK-JAX52afG609dLcGavSN624Ymn2WWZMA24kREDYVAE7YhEJZ1SsA5hgdje4NskjSZJ0NnhHOwEBuai2Pv6TVt05To2WevUXSuaLhDdM9D_nrIgiOnB32otyjrxpcxMGQBqSJ1D4FoKBNbPhWL0to1WOHwytpLZ6yb5R24ZaH5VKx0VlS7tT211cLHifEl1fNgfN93zwQ1VRIiMFrLxkksgT8hKg82_jjj4gFx1cpuhUffWCKs/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
