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>
wrote:
Thursday, 3 August 2023 20:14:41 CEST writes:
On Thu, Aug 3, 2023 at 1:23 PM Gould, James <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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
