Hello,
On 10/11/20 13:39, Dmitry Belyavsky wrote:
> Dear colleagues,
>
> Here is the updated version of the draft describing the usage of the
> Internationalized Email Addresses (EAI) in the EPP protocol.
> This version provides a specification to submit EAI to the registries via
> the EPP proto
Well,
On Mon, Oct 12, 2020 at 2:47 PM Thomas Corte (TANGO support) <
thomas.co...@knipp.de> wrote:
> Hello,
>
> On 10/11/20 13:39, Dmitry Belyavsky wrote:
>
> > Dear colleagues,
> >
> > Here is the updated version of the draft describing the usage of the
> > Internationalized Email Addresses (EAI
From: regext On Behalf Of Dmitry Belyavsky
Sent: Monday, October 12, 2020 8:11 AM
To: Thomas Corte (TANGO support)
Cc: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for
draft-belyavskiy-epp-eai-01.txt
Well,
On Mon, Oct 12, 2020 at 2:47 PM Thomas Corte (TANG
Dear Scott,
On Mon, Oct 12, 2020 at 3:20 PM Hollenbeck, Scott
wrote:
> *From:* regext *On Behalf Of *Dmitry Belyavsky
> *Sent:* Monday, October 12, 2020 8:11 AM
> *To:* Thomas Corte (TANGO support)
> *Cc:* regext@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Fwd: New Version Notification for
>
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the
IETF.
Title : JSON Responses for the Registration Data Access
Protocol (RDAP)
Authors : Scott Hollenbec
> -Original Message-
> From: regext On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:06 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis
>
> The WGLC for this document was scheduled to end today. While there is
> support to
> -Original Message-
> From: regext On Behalf Of James Galvin
> Sent: Friday, October 2, 2020 4:15 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis
>
> The WGLC for this document was scheduled to end today. While there is
> support to
In article <542572b0e6284550a9bee035bea2d...@verisign.com> you write:
> [SAH] Perhaps there’s a case to be made for RFC 6530 being an update to RFC
> 5322. I’m going to see if I can run some tests to
>confirm it, but I, too, suspect that EPP as-is won’t have any issues with
>internationalized e
We could update the contact scheme version to indicate the EAI support as
it is relevant for the contract mapping only.
On Mon, 12 Oct 2020, 18:51 John Levine, wrote:
> In article <542572b0e6284550a9bee035bea2d...@verisign.com> you write:
> > [SAH] Perhaps there’s a case to be made for RFC 653
Dmitry,
The mechanism that we’ve used in the past is signaling support in the EPP
greeting and login services. Support for an EPP extension is signaled per RFC
in the EPP greeting and login services. We signal support for an operation
practice via defining an XML namespace that is included in
Dear James,
If we indicate in the EPP greeting/Login support
of urn:ietf:params:xml:ns:contact-1.0
for old contact scheme without EAI and urn:ietf:params:xml:ns:contact-1.1
for a new scheme with EAI, will it be enough?
On Mon, Oct 12, 2020 at 10:53 PM Gould, James wrote:
> Dmitry,
>
>
>
> The m
Dimtry,
I don’t believe there is the need for a new contact XML namespace, but it would
be associated with the new XML namespace
(urn:ietf:params:xml:ns:epp:eppEAI-1.0) defined in draft-belyavskiy-epp-eai.
--
JG
[cid:image001.png@01D6A0B3.90BB6A40]
James Gould
Fellow Engineer
jgo...@verisi
Dear James,
We have some options that sound reasonable (for me)
1. Treat RFC 6530 as an update to RFC 5322 (not the best idea, really).
2. Indicate accepting EAI via new contact namespace, accept in the
tag
3. Indicate accepting EAI via eppEAI namespace, accept in the
tag
4. Indicate accepting
13 matches
Mail list logo
