Subject: Re: [regext] Internationalized Email Addresses and EPP

From: "Gould, James" <[email-masked]>
Date: Mon, 21 Dec 2020 13:28:06 +0000

I reviewed the Internationalized Email Addresses and EPP discussion on the list in detail.  I want to ensure that the options are clearly covered.  The EAI support options discussed thus far include:

1.       Do you want the EPP standard to support non-ASCII email addresses?
a.       Scott Hollenbeck’s review of the RFC 5322 reference in the EPP RFC 5733 resulted in the reference being appropriate since the EAI documents update the syntax specification found in 5322 *if* you choose to support the EAI SMTP extension.
b.       EAI support in EPP goes beyond EPP RFC 5733, where email addresses are also used in EPP RFC 8543, and additional EPP mapping registered in the EPP Extension Registry (e.g., Email Forwarding Mapping and NameWatch Mapping).
c.       I don’t support this option since EAI applies broader than a single EPP mapping (EPP RFC 5733), updating the RFC 5733 reference doesn’t address it, and EPP has an extensibility mechanism to handle this in a more explicit manner.
2.       Do you want to *extend* EPP to support non-ASCII addresses, as an option for those who implement the extension?
a.       I take the language from Scott Hollenbeck to support creating an EPP extension for EAI:
                                                                           i.      “The right way to tackle this is to create an EPP extension to allow EPP clients and servers to support EAI. That extension would need to include normative references to the  EAI RFCs, and it would need to allow internationalized email addresses in any EPP fields, including other extensions, that currently carry email addresses.”
b.       Extension options discussed on the list from least explicit to most explicit:
                                                                           i.      Define an Operational Practice (Alex Mayrhofer’s option 4)
1.       “Option 4 would be to not add an extension or a XML namespace for signaling and to return a 2306 error when EAi is not supported.”
2.       Alex’s proposal may be that it’s up to server-policy how to handle it with returning a 2306 error as a proposed choice.  Putting support for EAI into the camp of server-policy will make it a challenge for registrars since the registries can and most likely will make different server-policy decisions with no signaling to the client.  At a minimum, an operational policy should be defined with an XML namespace that signals support for the operational practice.
                                                                         ii.      EAI Support Based on Greeting and Login Services (session-level support for EAI)
1.       This option defines an operational practice and uses an XML namespace in the EPP greeting and login services to signal support within an individual EPP session.  All objects for all TLDs supported by the server would implicitly support EAI for the email elements.  With this option, there is no way to differentiate which TLDs and which objects within the TLDs support EAI.  This is very straight forward to implement, but I believe is far too course grain to provide meaning.
                                                                       iii.      EAI Support with Marker Extension Element (object-level support for EAI)
1.       This option defines an extension that is applied on a per-object basis.  A client can explicitly define that the email address for an object supports EAI and the server can explicitly define whether EAI is supported for that object.  There may be EPP object mappings that support multiple email elements, so this option implicitly defines the email elements that supports EAI on a per-objects basis.  I don’t believe there are any existing EPP object mappings that have an issue with use of a marker element.
                                                                       iv.      EAI Support with Placeholder Text and new Email Element (element-level support for EAI)
1.       This option defines an extension that is applied on an element basis, where the placeholder text defines the element explicitly.  This is the approach currently defined by draft-belyavskiy-epp-eai-02.  Since the existing EPP object mappings don’t have an issue with implicitly indicating the EAI element of an object, the Marker Extension Element looks to be a simpler option.

There was discussion on the list related to whether a EAI element should be returned to a client that does not support the EAI extension.  This comes down to an unhandled namespace problem that is defined by draft-ietf-regext-unhandled-namespaces; although in this case it applies to a field within a supported namespace (e.g., contact email element in EPP RFC 5733).  There are existing EPP object mappings (e.g., Contact, Organization, Email Forwarding, NameWatch) that have a mix of requiring the email address in the info response, so you can’t universally specify that the email element will not be returned to a client that doesn’t support EAI.  draft-ietf-regext-unhandled-namespaces can be used to indicate that the extension is not supported as a signal to the client, but the question is what to do with the required email element value.  One option is to return the value that is non-deterministic and the other option is to return a placeholder value (“[EAI-ADDRESS]”) that will be deterministic since “[EAI-ADDRESS]” is clearly not a valid e-mail address.  Both options should include an indication that EAI is not supported by the client via draft-ietf-regext-unhandled-namespaces.  I generally prefer to be deterministic, but providing the signal via draft-ietf-regext-unhandled-namespaces may be good enough.

Based on the feedback from the working group, I believe the best option is 2.b.iii “EAI Support with Marker Extension Element”.  We can cover in the draft how to handle the clients that don’t support EAI in a Implementation Considerations section.

--

JG

James Gould

Fellow Engineer

[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271

12061 Bluemont Way

Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 11/24/20, 1:57 PM, "regext on behalf of Taras Heichenko" <[email-masked] on behalf of [email-masked]> wrote:

    > On 24 Nov 2020, at 19:56, Patrick Mevzek <[email-masked]> wrote:

    > On Tue, Nov 24, 2020, at 12:35, Taras Heichenko wrote:

    >> First of all, registry does not force anything. It gives the

    >> possibility that registrars

    >> can use.

    > ... which then forces all other registrars to have to support that possibility,

    > except if the registry offers a way for registrars not wanting it to be able

    > to opt-out from it.

    > A registry is a shared data storage, in one simplified view. If registrar X

    > has the "possibility" to enter data there that registrar Y has no way to handle,

    > this means pretty much everyone is forced to upgrade in order to handle the new data.

    > Or just stop using that shared datastore.

    > Again, I think the purpose is to find a solution that could work

    > for any registry (so trying not to just create things for the benefit

    > of a sole actor, even if that happens too often to my taste), and any registrar,

    > including those that do not want to support that new feature, even if you personally

    > believe that all registrars should support it.

    > We can talk endlessly about a specific registry and a specific problem.

    > But I guess that if ones wants to have something akin to an RFC at least some

    > work is needed to include other actors in the play even if finally the specification

    > won't be used by more than one actor. Otherwise it can just be published as an I-D

    > or Informational RFC I guess, for just notification, and there is a little for the

    > working group to discuss (if the initial specification is not open to changes).

    You ask strange questions. There are DB with data that my interface does not support.

    How can I work with the DB under such circumstances? Really I do not have an answer

    to this question. It looks like "I wand use email but I do not want my software to correspond

    RFC 5322. What should I do?"

    >> But if there are users that want to use non-ASCII email then

    >> registrars

    >> and registries should give the ability to use such addresses to the

    >> users. (At least

    >> if we say about universal acceptance). So whether EAI would be

    >> implemented by

    >> extension or in the main <email> field it will bring all registrars to

    >> the EAI implementation.

    > That "either" might need only a couple of electrons in an email, but both options need

    > a non trivial amount of work: either designing a proper extension (without plays

    > on placeholders or things like that), or just doing "EPP v2" if you want to change

    > the "email" definition, and then good luck to make everyone switch to that.

    > (and if there is anytime a work towards EPP v2 there are other problems far

    > more pressing to fix there than just email).

    >> "it will bring all registrars to the EAI implementation."

    > I will let you believe that then, but 1) the IETF is not the protocol or policy police

    > even if the perfect solution is designed there is no guarantee anyone will use it

    > and

    I know what is IETF. But I dislike the approach: we made some standard from our

    heads and now you can do with it whatever you want. And I saw here thoughts that

    differ from yours from the people that are working in this area. What are we going to do?

    Maybe it is too early to adopt such a standard and we should wait until usage of non-ASCII

    email on the Internet would be more defined.

    From my point of view, the extension does not give any advantages. It makes the protocol

    more complicated and gives nothing back.

    > 2) a non technical problem can not be solved by a technical solution, no matter what

    > you will do here, each registrar has its own business case and can decide, from its

    > own point of view, if he wants to do that or not (and hence go up to not carrying the

    > TLD at all if there is no other solution). Which means that the registry has

    > to force by non technical means (aka: contracts) if it wants that behavior

    > (exactly like ICANN contracts mandates implementation of specific RFCs by registries

    > and registrars) or offer proper solutions for registrars not wanting to do it.

    > We can discuss here only the second part, if there is a change in current specifications

    > that allows nicely registrars wanting the feature and registrars not wanting the feature

    > to continue to work.

    > (also, you might be slightly forgetting the "transition" period. Even if registry X

    > says "ok in 6 months all email is EAI compatible, go fix your systems dear registrars",

    > and no matter what delay you give, it will be too short for some)

    > Look at DNSSEC and IPv6 for similar cases of "but everyone should be doing that,

    > it is even mandated by contracts" vs the sore reality of "yeah it kinda works at

    > some places but certainly not everywhere".

    > I think it is better to stick to proposal and see how they work.

    > Another options is to first document the problem and constraints space, and then

    > in a separate document offer a solution.

    > Making everyone first agreeing exactly on what problems need to be solved

    > can frame discussions efficiently.

    > --

    >  Patrick Mevzek

    >  [email-masked]

    > _______________________________________________

    > regext mailing list

    > [email-masked]

    > https://secure-web.cisco.com/1CTt8nOMG99IqphFt7XQvrwshCktjtLvNq_NrApuvQgDbeD0AC-sf41PcRBFC3tkK1CGOwYbeMkRsfeqiwzJ0XXLnnoUwRY9zF74PibtIJG6pKkI9L1fBmBvHohQ_4fp6EItQQ6QOcgdYgenY0tA3vH4JNp0YXlRaJ-YEygStgyeVhYVagew8DH2NSsKzZaX7FtP9kZaqTJyLH4mdOUAK07Eg6jKSa1rF_ocwlmBh6Vy93Z16dVHRbOk-n47KbZz9adUz6tERG3KJRLJhxcoM0qsnsY2Dr3eJo3tfm8ZmCH0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

    --

    Taras Heichenko

    [email-masked]

    _______________________________________________

    regext mailing list

    [email-masked]

    https://secure-web.cisco.com/1CTt8nOMG99IqphFt7XQvrwshCktjtLvNq_NrApuvQgDbeD0AC-sf41PcRBFC3tkK1CGOwYbeMkRsfeqiwzJ0XXLnnoUwRY9zF74PibtIJG6pKkI9L1fBmBvHohQ_4fp6EItQQ6QOcgdYgenY0tA3vH4JNp0YXlRaJ-YEygStgyeVhYVagew8DH2NSsKzZaX7FtP9kZaqTJyLH4mdOUAK07Eg6jKSa1rF_ocwlmBh6Vy93Z16dVHRbOk-n47KbZz9adUz6tERG3KJRLJhxcoM0qsnsY2Dr3eJo3tfm8ZmCH0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext