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 Holl
> On 24 Nov 2020, at 19:56, Patrick Mevzek 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
> p
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 wa
> On 24 Nov 2020, at 16:38, Patrick Mevzek wrote:
>
>
>
> On Tue, Nov 24, 2020, at 02:19, Taras Heichenko wrote:
>> Two notes:
>> - the authinfo field in a Contact object allows opening personal data
>> to only one registrar
>
> So... domain:authInfo is not good enough to authenticate the
> -Original Message-
> From: regext On Behalf Of Patrick Mevzek
> Sent: Tuesday, November 24, 2020 9:39 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
[snip]
> > I just wanted to say that if a regist
On Tue, Nov 24, 2020, at 02:19, Taras Heichenko wrote:
> Two notes:
> - the authinfo field in a Contact object allows opening personal data
> to only one registrar
So... domain:authInfo is not good enough to authenticate the owner to do the
transfer...
but contact:authInfo is good enough to r
> On 24 Nov 2020, at 01:26, Patrick Mevzek wrote:
>
>
>
> On Mon, Nov 23, 2020, at 18:12, Taras Heichenko wrote:
>>> This is completely orthogonal to anything related to email addresses.
>>> Long gone are the days when only an email sent was enough to trigger a
>>> transfer,
>>> and for goo
On Mon, Nov 23, 2020, at 18:12, Taras Heichenko wrote:
> > This is completely orthogonal to anything related to email addresses.
> > Long gone are the days when only an email sent was enough to trigger a
> > transfer,
> > and for good reasons.
>
> I said nothing about only an email address but
> On 23 Nov 2020, at 23:55, Patrick Mevzek wrote:
>
>
>
> On Mon, Nov 23, 2020, at 16:50, Taras Heichenko wrote:
>> Just a question: How can a registrar accept the transfer of a domain by
>> a user if it does
>> not check that this domain is owned by this user?
>
> You may want to look at
On Mon, Nov 23, 2020, at 16:50, Taras Heichenko wrote:
> Just a question: How can a registrar accept the transfer of a domain by
> a user if it does
> not check that this domain is owned by this user?
You may want to look at ...
This is completely orthogonal to anything related to email addr
> On 23 Nov 2020, at 23:39, Patrick Mevzek wrote:
>
>
>
> On Mon, Nov 23, 2020, at 15:55, John Levine wrote:
>> In article you write:
>>> [SAH] I’m not talking about rejecting a transfer. I’m talking about what a
>>> registrar that does not support EAI would/should do if
>>> it is the rece
> On 23 Nov 2020, at 22:55, John Levine wrote:
>
> In article you write:
>> [SAH] I’m not talking about rejecting a transfer. I’m talking about what a
>> registrar that does not support EAI would/should do if
>> it is the receiving registrar of a domain that includes contacts using
>> inter
On Mon, Nov 23, 2020, at 15:55, John Levine wrote:
> In article you write:
> > [SAH] I’m not talking about rejecting a transfer. I’m talking about what
> > a registrar that does not support EAI would/should do if
> >it is the receiving registrar of a domain that includes contacts using
> >in
On Mon, Nov 23, 2020, at 16:05, Dmitry Belyavsky wrote:
>
> If I remember correctly, there is a closed list of reasons to reject
> the transfer for the gTLDs.
Correct but that is for the outgoing (current) registrar not for the prospective
(new) one. Current one has no reason to reject thing
@ietf.org; Gould, James
>> ; alex.mayrhofer.i...@gmail.com
>> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
>>
>> Caution: This email originated from outside the organization. Do not click
>> links
>> or open attachments unless you recogn
On Mon, 23 Nov 2020, 21:55 John Levine, wrote:
> In article you write:
> > [SAH] I’m not talking about rejecting a transfer. I’m talking about
> what a registrar that does not support EAI would/should do if
> >it is the receiving registrar of a domain that includes contacts using
> internation
In article you write:
> [SAH] I’m not talking about rejecting a transfer. I’m talking about what a
> registrar that does not support EAI would/should do if
>it is the receiving registrar of a domain that includes contacts using
>internationalized email addresses and those addresses aren’t
>sup
On Mon, Nov 23, 2020, at 08:59, Hollenbeck, Scott wrote:
> This may be the path of least resistance. I'm still trying to think
> through hat would happen if a registry returns an internationalized
> email address to a registrar that doesn't expect one. This could happen
> after a domain transfer
On Mon, Nov 23, 2020, at 10:00, Dmitry Belyavsky wrote:
> From my point of view, if the registry has implemented EAI support, all
> the registrars will have to do it. They should deal with the clients
> with such emails _somehow_.
Why do we want to design protocols that have the unfortunate con
From: Dmitry Belyavsky
Sent: Monday, November 23, 2020 10:00 AM
To: Hollenbeck, Scott
Cc: alex.mayrhofer.i...@gmail.com; Gould, James ;
regext@ietf.org; klaus.malo...@knipp.de
Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
Caution: This email originated from
> -Original Message-
> From: Taras Heichenko
> Sent: Monday, November 23, 2020 1:46 PM
> To: Dmitry Belyavsky
> Cc: Hollenbeck, Scott ;
> klaus.malo...@knipp.de; regext@ietf.org; Gould, James
> ; alex.mayrhofer.i...@gmail.com
> Subject: [EXTERNAL] Re: [regext]
Hi!
> On 23 Nov 2020, at 17:00, Dmitry Belyavsky wrote:
>
> Dear Scott,
>
[skip]
>
> This may be the path of least resistance. I'm still trying to think through
> hat would happen if a registry returns an internationalized email address to
> a registrar that doesn't expect one. This could
On Thu, Nov 19, 2020, at 10:20, Klaus Malorny wrote:
> What I regard as suboptimal in respect to the proposed EPP extension [1]
> is the big effort for the little issue (RFC-wise and
> implementation-wise), and also using this dummy placeholder [EAI-DUMMY]
Using such kind of placeholder, like i
Alex,
How to handle input EAI values (create or update) can result in an error (e.g.,
2306) based on server policy independent of the use of the extension. The
extension provides for signaling by the client of the EAI support, which
enables the server to fast-fail when it's not allowed. The
@ietf.org
> > Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and
> EPP
> >
> > Caution: This email originated from outside the organization. Do not
> click links
> > or open attachments unless you recognize the sender and know the content
Hello
> > -Original Message-
> > From: Alexander Mayrhofer
> > Sent: Monday, November 23, 2020 1:04 AM
> > To: Gould, James
> > Cc: klaus.malo...@knipp.de; Hollenbeck, Scott
> > ; regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] Int
> -Original Message-
> From: Alexander Mayrhofer
> Sent: Monday, November 23, 2020 1:04 AM
> To: Gould, James
> Cc: klaus.malo...@knipp.de; Hollenbeck, Scott
> ; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
&g
Jumping into this discussion quite late, but...
On Thu, Nov 19, 2020 at 4:39 PM Gould, James
wrote:
> The 3 options presented and discussed at the REGEXT meeting included three
> extension options, which all include an namespace URI in the greeting and
> logic services:
I'd really like to und
Sent: Friday, November 20, 2020 6:13 AM
> To: Hollenbeck, Scott mailto:shollenb...@verisign.com>>
> Cc: klaus.malo...@knipp.de <mailto:klaus.malo...@knipp.de>;
regext@ietf.org <mailto:regext@ietf.org>
> Subject: [EXTERNAL] Re: [regext] Internationalized Emai
> On 20 Nov 2020, at 11:06, Hollenbeck, Scott
> > wrote:
> > >
> > >> -Original Message-
> > >> From: regext On Behalf Of Klaus Malorny
> > >> Sent: Friday, November 20, 2020 3:47 AM
> > >> To: regext@ietf.org
> > >>
> -Original Message-
> From: Taras Heichenko
> Sent: Friday, November 20, 2020 6:13 AM
> To: Hollenbeck, Scott
> Cc: klaus.malo...@knipp.de; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
>
> Caution: This email ori
> On 20 Nov 2020, at 11:06, Hollenbeck, Scott
> wrote:
>
>> -Original Message-
>> From: regext On Behalf Of Klaus Malorny
>> Sent: Friday, November 20, 2020 3:47 AM
>> To: regext@ietf.org
>> Subject: [EXTERNAL] Re: [regext] Internationalized
> -Original Message-
> From: regext On Behalf Of Klaus Malorny
> Sent: Friday, November 20, 2020 3:47 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
>
> Caution: This email originated from outside the organ
On 19.11.20 19:14, Gould, James wrote:
Klaus,
The EAI support goes beyond RFC 5733 and is a perfect example of the use of the
extensibility built into EPP. Revising the RFCs and EPP extensions that use
email addresses for EAI with new XML namespaces and potentially other changes
is much more
Klaus,
The EAI support goes beyond RFC 5733 and is a perfect example of the use of the
extensibility built into EPP. Revising the RFCs and EPP extensions that use
email addresses for EAI with new XML namespaces and potentially other changes
is much more impactful than creating an EPP extension
On 19.11.20 16:37, Gould, James wrote:
Klaus,
[...]
2. Implicit Replacement Based on Login Services – Inclusion of the
namespace URI in the greeting and login services indicate support
for EAI addresses implicitly. This would be treated similar to an
EPP extension with the names
> -Original Message-
> From: Klaus Malorny
> Sent: Thursday, November 19, 2020 10:21 AM
> To: Hollenbeck, Scott
> Cc: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
>
> Caution: This email originated from outside
Klaus,
The 3 options presented and discussed at the REGEXT meeting included three
extension options, which all include an namespace URI in the greeting and logic
services:
1. Placeholder Text and a New Email Element – This matches
https://tools.ietf.org/html/draft-belyavskiy-epp-eai-01
Hi Scott et al.,
sorry for proposing the following so late in the discussion. Due to
other duties, my visits to the list were less frequent in the recent
time. Looking at the two options - update of RFC 5733 or an extension -,
I probably would tend to the first option, but I understand the p
> -Original Message-
> From: Barry Leiba
> Sent: Monday, October 19, 2020 5:48 AM
> To: Hollenbeck, Scott
> Cc: art-...@ietf.org; regext@ietf.org
> Subject: [EXTERNAL] Re: Internationalized Email Addresses and EPP
>
> Hi, Scott,
>
> An interesting question...
>
> I think it depends upon h
-10-19 17:48
To: Hollenbeck, Scott
CC: art-...@ietf.org; regext@ietf.org
Subject: Re: [regext] Internationalized Email Addresses and EPP
Hi, Scott,
An interesting question...
I think it depends upon how you want this to appear from an EPP point of view:
1. Do you want the EPP standard to support
From: Dmitry Belyavsky
Sent: Monday, October 19, 2020 4:12 PM
To: Hollenbeck, Scott
Cc: Gould, James ; jo...@taugh.com; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
On Mon, Oct 19, 2020 at 10:03 PM Hollenbeck, Scott
mailto:40verisign
Many things are usually allowed by the EPP Schemas but refused according
to server policies so it seems to me that this case is similar to many
others. For example, are registrars aware of the TLDs implementing
DNSSEC or do they simply rely on finding the DNSSEC namespace in EPP
greeting?
Bes
On Mon, Oct 19, 2020 at 10:03 PM Hollenbeck, Scott wrote:
> > -Original Message-
> > From: regext On Behalf Of Gould, James
> > Sent: Monday, October 19, 2020 2:50 PM
> > To: jo...@taugh.com; regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] Interna
> -Original Message-
> From: regext On Behalf Of Gould, James
> Sent: Monday, October 19, 2020 2:50 PM
> To: jo...@taugh.com; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
>
> John,
>
> The signal would be han
John,
The signal would be handled via support for an EPP extension XML namespace in
option 2, an operational practice XML namespace in what I would call 2b, or
most likely a new contact XML namespace (contact-1.1) in option 1 for RFC 5733.
The XML namespace would be reflected in the EPP greeti
In article <5f5d3bae-b38c-4663-800b-3f5918990...@verisign.com> you write:
>
>The registry can support the receipt of UTF-8 addresses based on the EPP RFCs,
>but full support comes down to the validation of the
>email addresses, how the email addresses are stored, and what the email
>addresses are
John,
The registry can support the receipt of UTF-8 addresses based on the EPP RFCs,
but full support comes down to the validation of the email addresses, how the
email addresses are stored, and what the email addresses are used for. I would
expect an EPP error (2004 "Parameter value range err
In article <95c042c2-e77b-6f92-acb6-4a35663b1...@iit.cnr.it> you write:
>+1 for (1).
>> 1. Do you want the EPP standard to support non-ASCII email addresses?
Do we believe that every registry that supports EPP can handle UTF-8
addresses? If not, what happens when a regstrar sends a UTF-8 address
20190
Verisign.com<http://verisigninc.com/>
From: Dmitry Belyavsky
Date: Monday, October 19, 2020 at 12:50 PM
To: James Gould
Cc: "barryle...@computer.org" , "Hollenbeck, Scott"
, "art-...@ietf.org" ,
"regext@ietf.org"
Subject: [EXTERNAL] Re: [reg
+1 for (1).
Best
Mario
Il 19/10/2020 11:48, Barry Leiba ha scritto:
Hi, Scott,
An interesting question...
I think it depends upon how you want this to appear from an EPP point of view:
1. Do you want the EPP standard to support non-ASCII email addresses?
2. Do you want to *extend* EPP to s
Let me disagree...
Login Security Extension does much more than just increasing the password
length.
Going(2) means that EAI addresses are not first-class citizens, that seems
wrong for now.
Also, the current schema definition formally allows EAI addresses.
On Mon, Oct 19, 2020 at 7:23 PM Gould,
I believe option 2 is the better route to go. We went with option 2 to extend
the password length in RFC 5730 with the Login Security Extension (RFC 8807).
The use of email addresses in EPP is not isolated to RFC 5733. The
Organization Mapping (RFC 8543) and some additional EPP mappings regis
Hi, Scott,
An interesting question...
I think it depends upon how you want this to appear from an EPP point of view:
1. Do you want the EPP standard to support non-ASCII email addresses?
2. Do you want to *extend* EPP to support non-ASCII email addresses,
as an option for those who implement th
Barry, Murray:
We have a question about IETF process as it related to updating an Internet
Standard document. RFC 5733 ("Extensible Provisioning Protocol (EPP) Contact
Mapping", part of Standard 69) was published in August 2009. It includes a
normative reference to RFC 5322 for the definition o
55 matches
Mail list logo
