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://verisigninc.com/>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
