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
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/>
On 11/24/20, 1:57 PM, "regext on behalf of Taras Heichenko"
<regext-boun...@ietf.org on behalf of ta...@academ.kiev.ua> wrote:
> On 24 Nov 2020, at 19:56, Patrick Mevzek <p...@dotandco.com> 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
> p...@dotandco.com
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
>
https://secure-web.cisco.com/1CTt8nOMG99IqphFt7XQvrwshCktjtLvNq_NrApuvQgDbeD0AC-sf41PcRBFC3tkK1CGOwYbeMkRsfeqiwzJ0XXLnnoUwRY9zF74PibtIJG6pKkI9L1fBmBvHohQ_4fp6EItQQ6QOcgdYgenY0tA3vH4JNp0YXlRaJ-YEygStgyeVhYVagew8DH2NSsKzZaX7FtP9kZaqTJyLH4mdOUAK07Eg6jKSa1rF_ocwlmBh6Vy93Z16dVHRbOk-n47KbZz9adUz6tERG3KJRLJhxcoM0qsnsY2Dr3eJo3tfm8ZmCH0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
--
Taras Heichenko
ta...@academ.kiev.ua
_______________________________________________
regext mailing list
regext@ietf.org
https://secure-web.cisco.com/1CTt8nOMG99IqphFt7XQvrwshCktjtLvNq_NrApuvQgDbeD0AC-sf41PcRBFC3tkK1CGOwYbeMkRsfeqiwzJ0XXLnnoUwRY9zF74PibtIJG6pKkI9L1fBmBvHohQ_4fp6EItQQ6QOcgdYgenY0tA3vH4JNp0YXlRaJ-YEygStgyeVhYVagew8DH2NSsKzZaX7FtP9kZaqTJyLH4mdOUAK07Eg6jKSa1rF_ocwlmBh6Vy93Z16dVHRbOk-n47KbZz9adUz6tERG3KJRLJhxcoM0qsnsY2Dr3eJo3tfm8ZmCH0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
