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://verisigninc.com/>
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
