Jim, It’s too bad that you didn’t weigh in when I requested for opinions with the mailing list thread https://mailarchive.ietf.org/arch/msg/regext/V5znHXurkApuTJaL_GOyQUYMddw/ in March. For SMTPUTF8 to be used, there must be a policy decision made by all three R’s (Registry, Registrar, and Registrant), so there is no concept of being “out of luck”. When it’s implemented, there are multiple alternate forms of communication (postal address, voice, and fax) that can be used for insurance. Your proposal will require having a permanent ASCII alternate email, since draft -17 received negative feedback related to having a transition period. If an ASCII email is always required, SMTPUTF8 email addresses will never be used as first-class citizens in EPP. Do you see the need for an ASCII email as a permanent requirement?
You stated, “If we’re going to stand firm on the current working group consensus, then I believe the question to be answered is why EPP is special and shouldn’t be required to align with accepted practice?” What accepted practice are you referring to? Now acting in your role as chair, how do we establish consensus now that you as an individual don’t support the working group consensus? 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: James Galvin <gal...@elistx.com> Date: Thursday, July 27, 2023 at 7:05 PM To: James Gould <jgo...@verisign.com> Cc: "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. Speaking as an individual, I don’t believe this responds to the issue at hand. I understand this to be suggesting that EPP is telling the world that a registrant is welcome to use an SMTPUTF8 email address and the rest of the world is out of luck if you can’t handle that email address. Well, in fairness, what the text says is if you can’t use email, for whatever reason, then try some other method of contact. If I’m wrong about that then the rest of this message won’t make sense and you can stop reading here. Assuming that’s correct, my problem with that is it doesn’t align with the principles of the email standards and practices according to the IETF. If we’re going to stand firm on the current working group consensus, then I believe the question to be answered is why EPP is special and shouldn’t be required to align with accepted practice? Suggesting that if email doesn’t work an Internet user trying to contact a registrant should just use something else just doesn’t pass the “sniff test” for me. EPP is dictating to registrants their options and, in particular, telling anybody who wants to use EPP for their registration system they should *not* use an SMTPUTF8 email address if you actually want to be contacted until the entire Internet has converted to making SMTPUTF8 the default. Coming at this from a different direction, speaking as a registry operator, I want my registrants to be able to have service regardless of the circumstances. I won’t always require an alternate email address, but for those registrants that want it I want to make sure it is supported on behalf of registrants. Keep in mind, registrants may *both* want to use a “modern” email address and make sure that anyone can contact them. This proposal does not allow this. I am not supportive of the current working group consensus and would prefer we go back to a model we had at one time which is to allow for a simple extension to be defined that allows a second email address to be captured. There’s a few more details to be specified with that solution but the concept is simple, sound, and ensures that everyone has the option to do things according to their local policy. Jim On 27 Jul 2023, at 9:48, Gould, James wrote: Based on the discussion that occurred at the IETF-117 REGEXT meeting, I took the action item to cover the topic of the alternate ASCII e-mail. To address this, I defined a new “Alternate Communication Considerations” section with the following content for consideration: RFC 6530<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC6530> [RFC6530<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC6530>] specifies "message-originating systems SHOULD be prepared to either send conventional envelopes and message headers or to return the message to the originating user so the message may be manually downgraded to the traditional form" along with "Of course, such transformations imply that the originating user or system must have ASCII-only addresses available for all senders and recipients. Mechanisms by which such addresses may be found or identified are outside the scope of these specifications as are decisions about the design of originating systems". This implies that adding support for SMTPUTF8 in EPP includes the need for an alternate form of communication in event of SMTPUTF8 communication errors. Having alternate forms of communication is the responsibility of server policy on a per EPP extension basis. The two known EPP extension RFCs that have email addresses, that include RFC 5733<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC5733> [RFC5733<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC5733>] and RFC 8543<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC8543>[RFC8543<file:///Users/jgould/projects/github/eppeai/draft-ietf-regext-epp-eai.html#RFC8543>], support alternate forms of communication in the form of postal address, voice telephone number, and facsimile telephone number. Use of an alternate ASCII email address can be used by an EPP extension. Servers that do support this extension SHOULD ensure that there are available alternate communication methods for supported EPP extensions with email addresses. Please review and provide your feedback. If this section addresses the action item, -19 will be posted with it. 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://secure-web.cisco.com/1D9TQWLlu0-sTLl7_NuvA-HTeHfbVZUUH_l2HxGeMdZEJVELYdKg3ocFbkl7PoqCkv2tVw2rRUYogV2y5sOPD9dCZKKdpf5y4uiu9j9oUxU_lRIRgvoNbR1Xb5mJResMwYASthfW63IAZc9wITkl6gU-N3gz4ethDofVc3Y0tisuHJHuQPllEHHHXQRKuH9YzpP1cquTFa9G7G1VoNfZapG_JjTispyCCZwgOxSdiOu5Aacr7flvjmA1ySzBnpNcrcvN3XunXnA-9wRZRIcDT2N15NfvzFnoshIL9B6P4KSU/http%3A%2F%2Fverisigninc.com%2F> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1q3fvkz0BWqi8RVCOFiGyZZBDcSuWyMWwPGEhb8WrUms_CahG-_EcnHV-a2YDHxP3dNNUp8dRfSrorUarg9Bs59W9M135l_4RNiB_fDEK1mkv_XyFOklN1trM__7vmd6r2j7qwLhIIShDHVBQ8SfSQHR3bUmCLm3Km6MW8O7rBf78ZXlBPdDGCJYPcWhbSb7613ur2GGYbtnQbQqZcWWLTa1PR4c5-zvVS5NjhElwVo4cLtBLs3fAL_ujk6g8OC8kH4EljY-JuR2XTDrUkuiOnYlJNVitBWjAdSSDQ8uQIug/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
