Responding only to this one issue:
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?
Thank you for the question.
As co-Chair, I completely support the working group consensus. I have
demonstrated this by agreeing with our co-Chair on the prior consensus
call and acting on that consensus by submitting the document to the IESG
for publication.
What I didn’t and don’t support is the technical choice made by the
working group; I was clearly in the minority in the working group then,
and probably now. What I’m doing at this time is being more explicit
about my opinion given the response from our Area Director regarding the
content of this document.
As I understand the position of our Area Director, he is questioning the
technical choice of the working group. What he is asking for is either
an explicit explanation for why this working group is making the choice
it’s making, if we are not open to making an alternate choice.
So, I’m taking this opportunity to speak out more “loudly”
regarding an alternate position.
Antoin and I will be considering working group consensus together, and I
will certainly be deferential to his point of view on consensus since
I’m participating in this discussion.
Of course, if you have a concern please do let me know. Your co-Chair
and Area Director are also available to discuss any concerns you may
have if you (or anyone) are not comfortable discussing them with me
directly.
Thanks,
Jim
On 27 Jul 2023, at 23:31, Gould, James wrote:
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*[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: James Galvin <[email protected]>
Date: Thursday, July 27, 2023 at 7:05 PM
To: James Gould <[email protected]>
Cc: "[email protected]" <[email protected]>
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*[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
