Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Thomas Corte (TANGO support) 
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 protocol extension.
> 
> Any feedback is welcomed!

As James already pointed out, I'm not sure why the extension is even
necessary to accomplish this on a purely technical (protocol) level.

eppcom:minTokenType is based on xsd:token, which is based on
xsd:normalizedString and adds whitespace collapsing. Unless that
introduces a problem I'm not a aware of, none of this prevents the
specification of internationalized e-mail addresses for contacts in EPP;
in particular, it doesn't limit the available characters to ASCII.

Many registries (like e.g. Neustar for .biz, or the TLDs run by our own
TANGO system) already accept them right now. It would be silly to require
them to use an extension to do the same in the future.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbHThomas Corte
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund  E-Mail: thomas.co...@knipp.de
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Dmitry Belyavsky 
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) in the EPP protocol.
> > This version provides a specification to submit EAI to the registries via
> > the EPP protocol extension.
> >
> > Any feedback is welcomed!
>
> As James already pointed out, I'm not sure why the extension is even
> necessary to accomplish this on a purely technical (protocol) level.
>
> eppcom:minTokenType is based on xsd:token, which is based on
> xsd:normalizedString and adds whitespace collapsing. Unless that
> introduces a problem I'm not a aware of, none of this prevents the
> specification of internationalized e-mail addresses for contacts in EPP;
> in particular, it doesn't limit the available characters to ASCII.
>
> Many registries (like e.g. Neustar for .biz, or the TLDs run by our own
> TANGO system) already accept them right now. It would be silly to require
> them to use an extension to do the same in the future.
>

If the registries work this way, it's great but it means they formally
violate the EPP protocol.

https://tools.ietf.org/html/rfc5733#section-2.6 denotes:

   Email address syntax is defined in [RFC5322].  This mapping does not
   prescribe minimum or maximum lengths for character strings used to
   represent email addresses.

EAI addresses do not fit the RFC 5322.

The 1st version of the draft was basically replacing RFC 5322 to RFC 6530 :)

-- 
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Hollenbeck, Scott 
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 (TANGO support) 
mailto: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) in the EPP protocol.
   > This version provides a specification to submit EAI to the registries via
   > the EPP protocol extension.
   >
   > Any feedback is welcomed!

   As James already pointed out, I'm not sure why the extension is even
   necessary to accomplish this on a purely technical (protocol) level.

   eppcom:minTokenType is based on xsd:token, which is based on
   xsd:normalizedString and adds whitespace collapsing. Unless that
   introduces a problem I'm not a aware of, none of this prevents the
   specification of internationalized e-mail addresses for contacts in EPP;
   in particular, it doesn't limit the available characters to ASCII.

   Many registries (like e.g. Neustar for .biz, or the TLDs run by our own
   TANGO system) already accept them right now. It would be silly to require
   them to use an extension to do the same in the future.



   If the registries work this way, it's great but it means they formally 
violate the EPP protocol.



   
https://tools.ietf.org/html/rfc5733#section-2.6
 denotes:



  Email address syntax is defined in [RFC5322].  This mapping does not
  prescribe minimum or maximum lengths for character strings used to
  represent email addresses.



   EAI addresses do not fit the RFC 5322.



   The 1st version of the draft was basically replacing RFC 5322 to RFC 6530 :)



   [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 email 
addresses.



   Scott

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Dmitry Belyavsky 
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
> draft-belyavskiy-epp-eai-01.txt
>
>
>
> 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) in the EPP protocol.
> > This version provides a specification to submit EAI to the registries via
> > the EPP protocol extension.
> >
> > Any feedback is welcomed!
>
> As James already pointed out, I'm not sure why the extension is even
> necessary to accomplish this on a purely technical (protocol) level.
>
> eppcom:minTokenType is based on xsd:token, which is based on
> xsd:normalizedString and adds whitespace collapsing. Unless that
> introduces a problem I'm not a aware of, none of this prevents the
> specification of internationalized e-mail addresses for contacts in EPP;
> in particular, it doesn't limit the available characters to ASCII.
>
> Many registries (like e.g. Neustar for .biz, or the TLDs run by our own
> TANGO system) already accept them right now. It would be silly to require
> them to use an extension to do the same in the future.
>
>
>
> If the registries work this way, it's great but it means they formally
> violate the EPP protocol.
>
>
>
> https://tools.ietf.org/html/rfc5733#section-2.6
> 
> denotes:
>
>
>
>Email address syntax is defined in [RFC5322].  This mapping does not
>prescribe minimum or maximum lengths for character strings used to
>represent email addresses.
>
>
>
> EAI addresses do not fit the RFC 5322.
>
>
>
> The 1st version of the draft was basically replacing RFC 5322 to RFC 6530
> :)
>
>
>
> *[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
> email addresses.*
>
>
>
> *Scott*
>

I'm sure EPP itself will not. Do you think it's reasonable to indicate such
support via an extension or just leave it as a registry (internal) policy?

-- 
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] I-D Action: draft-ietf-regext-rfc7483bis-03.txt

2020-10-12 Thread internet-drafts 


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 Hollenbeck
  Andy Newton
Filename: draft-ietf-regext-rfc7483bis-03.txt
Pages   : 85
Date: 2020-10-12

Abstract:
   This document describes JSON data structures representing
   registration information maintained by Regional Internet Registries
   (RIRs) and Domain Name Registries (DNRs).  These data structures are
   used to form Registration Data Access Protocol (RDAP) query
   responses.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-rfc7483bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rfc7483bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rfc7483bis-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7483bis

2020-10-12 Thread Hollenbeck, Scott 
> -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 move the document forward there are two minor comments that
> have been raised during the last call.
>
> The chairs would like to hear from other working group members as to what
> to do with these comments.  Rather than close the last call and risk another
> last call, we are extending this last call for another week.  If we can come 
> to a
> consensus as to how to proceed before the end of last call than the
> document can stay on track to be submitted to the IESG after the last call.
>
> The WG last call will end at close of business on Friday, 9 October 2020.
>
>
>
> Here are the comments as seen on the mailing list.  Please respond with
> your suggestions regarding these two comments.
>
>
>
> James Gould:
>
> I have one item to bring up with draft-ietf-regext-rfc7483bis, which is
> associated with Section 5.1 “The Entity Object Class”.   The jCard
> "version" and "fn" members are required according to RFC 6350, which
> poses an issue if a contact name does not exist or needs to be redacted.
>   To address this case, I recommend adding a sentence to the end of
> section 3 "Common Data Types":
>
> Contact information is defined using jCards as described in [RFC7095].
> The “version” and “fn” members are required according to
> [RFC6350], where an empty “fn” member MAY be used when the contact
> name does not exist or is redacted.
>
> Two response have been offered:
>
> Scott Hollenbeck:
>
> I'd like to see some discussion of this suggestion. If one understands
> the normative references, the suggestion is already implicitly
> addressed. There may be some value in describing this situation
> explicitly since it came up in the ICANN gTLD implementation context,
> but so others think this clarification is necessary?
>
> Jasdip Singh:
>
> Seems if the RDAP profile for the DNRs
> (https://secure-
> web.cisco.com/11khs_gD3RqFuWkwSmkqxXidBMgZZIHUGiC-
> mnI0WBAe7ZaFAHesmDgIEQi6C5xdf4AFgOuCxci5Eg7TKAZOYRCMTpkn4HpQ
> A0IDR_way6sBg1J7G75Fc6554SdNlt4CZkx6Y4of235gC9pdotYdG-
> DmTSKFkMu7EbRZFxRQq2wuuUIJrvrbPz8ZGCf81LYvWGTfZrUMt-
> DtcEm1hz8yHyNC2J1hOc_6YhTLsOG_N5ZHM81dqp6v_HPIIN9ppz69MwuaZA
> ao62RBYsmFe3OyFzQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpa
> ges%2Frdap-operational-profile-2016-07-26-en)
> could clarify this, the spec could be left as-is.

[SAH] I just updated the document to address this feedback.

> Mario Loffredo:
>
> The document does not contain any requirement or recommendation about
> when returning ldhName and unicodeName values. However, the examples
> seem to convey the idea that ldhName must  always be returned and
> unicodeName must be returned in case of an IDN.

[SAH] There was no additional discussion, so I left this one alone.

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

2020-10-12 Thread Hollenbeck, Scott 
> -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 move the document forward there is one minor comment that
> has been raised during the last call.
>
> The chairs would like to hear from other working group members as to what
> to do with this comment.  Rather than close the last call and risk another 
> last
> call, we are extending this last call for another week.  If we can come to a
> consensus as to how to proceed before the end of last call than the
> document can stay on track to be submitted to the IESG after the last call.
>
> The WG last call will end at close of business on Friday, 9 October 2020.
>
>
> Here are the comments as seen on the mailing list.  Please respond with
> your suggestions regarding these two comments.
>
>
> James Gould:
>
> Yes, lumping the registrar object with the contact object under a single
> RDAP entity object interface is the rub.  We solved the problem in the
> RDAP Profile, by supporting entity lookup by IANA ID (number) and
> registrar name (string) for the registrar objects, and by ROID
> (“((\w|_){1,80}-\w{1,8}") for the contact objects.  Where there is
> overlap, which is registrar name (string) and ROID
> ((“((\w|_){1,80}-\w{1,8}") the contact takes precedence.  My
> recommendation is to provide guidance in the section 3.1.5 "Entity Path
> Segment Specification" for this real world case:
>
> The  parameter represents an entity (such as a contact,
> registrant, or registrar) identifier whose syntax is specific to the
> registration provider.  For example, for some DNRs, contact
> identifiers are specified in [RFC5730] and [RFC5733], and
> registrar identifiers are specified using the IANA Registrar ID
> assigned by ICANN.  The server SHOULD define a scheme
> for the  parameter to differentiate between the
> supported entity object types (e.g., contact and registrar),
> such as using different  formats, using a 
> precedence order, or a combination of formats and precedence
> order.
>
> The SHOULD could be a MUST, but the point is to provide guidance to
> implementers of the protocol.
>
> Two responses have been offered:
>
> Jasdip Singh response:
>
> One thought is if it could be in the RDAP profile doc for the DNRs
> (https://secure-web.cisco.com/1k4lL-
> ZaH_4UTeAlExqEDmWoj2i2M2JCucgN0US-
> ZRaw3P13LwsVyTwARJxQoKgUo1ceNGMGoZaum_o86c9qFXMK28e6HYprdo
> vBXG6JQKzs1SqqT5mQ_VEnMihHl3qiwMkTQ8qPKkPpbqOJbRIDs_UDppLFz2
> yhs97pm3Ssnh2DxotUzdWsgbWlESVZbLzMg5Z-
> ZTHevue2cVlwSwhdDlzQiyDBU4e0y9cLgcwXSXX7tJE5mUh04ocHwUI2Kcpqccf
> u_lM-
> d8029rv314sSAKQ/https%3A%2F%2Fwww.icann.org%2Fresources%2Fpages
> %2Frdap-operational-profile-2016-07-26-en).
> That way no need to update the spec.
>
> James Gould response:
>
> The RDAP Profile is dependent on the RFC, so I wouldn't create a
> circular dependency.  My recommendation is to take the lessons learned
> in implementing the RFC and provide guidance on how to handle it in the
> RFC directly.

[SAH] I don't think we reached consensus to change anything in the draft, so I 
left this one alone.

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread John Levine 
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 email addresses.

Urrgh.  RFC 6530 is not an update to 5322.  Don't go there.  I agree there is no
great technical problem sending UTF-8 address strings through EPP.

I'm getting the impression that what we need is a way for the client
to ask the registry whether it can handle EAI addresses so it knows
what to accept registrants.  I can imagine a variety of ways to do that.

R's,
John

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Dmitry Belyavsky 
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 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 email addresses.
>
> Urrgh.  RFC 6530 is not an update to 5322.  Don't go there.  I agree there
> is no
> great technical problem sending UTF-8 address strings through EPP.
>
> I'm getting the impression that what we need is a way for the client
> to ask the registry whether it can handle EAI addresses so it knows
> what to accept registrants.  I can imagine a variety of ways to do that.
>
> R's,
> John
>
> ___
> 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

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Gould, James 
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 the EPP greeting and 
login services.  See 
https://tools.ietf.org/html/draft-ietf-regext-secure-authinfo-transfer-03#section-3
 for signaling support for draft-ietf-regext-secure-authinfo-transfer, and see 
https://tools.ietf.org/html/draft-ietf-regext-unhandled-namespaces-03#section-4 
for signaling support for draft-ietf-regext-unhandled-namespaces.

--

JG

[cid:image001.png@01D6A0AF.CE2B3F30]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext  on behalf of Dmitry Belyavsky 

Date: Monday, October 12, 2020 at 3:16 PM
To: John Levine 
Cc: "Hollenbeck, Scott" , "regext@ietf.org" 

Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-01.txt

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, 
mailto:jo...@taugh.com>> wrote:
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 email addresses.

Urrgh.  RFC 6530 is not an update to 5322.  Don't go there.  I agree there is no
great technical problem sending UTF-8 address strings through EPP.

I'm getting the impression that what we need is a way for the client
to ask the registry whether it can handle EAI addresses so it knows
what to accept registrants.  I can imagine a variety of ways to do that.

R's,
John

___
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

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Dmitry Belyavsky 
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 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 the
> EPP greeting and login services.  See
> https://tools.ietf.org/html/draft-ietf-regext-secure-authinfo-transfer-03#section-3
> for signaling support for draft-ietf-regext-secure-authinfo-transfer, and
> see
> https://tools.ietf.org/html/draft-ietf-regext-unhandled-namespaces-03#section-4
> for signaling support for draft-ietf-regext-unhandled-namespaces.
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *regext  on behalf of Dmitry Belyavsky <
> beld...@gmail.com>
> *Date: *Monday, October 12, 2020 at 3:16 PM
> *To: *John Levine 
> *Cc: *"Hollenbeck, Scott" , "regext@ietf.org" <
> regext@ietf.org>
> *Subject: *[EXTERNAL] Re: [regext] Fwd: New Version Notification for
> draft-belyavskiy-epp-eai-01.txt
>
>
>
> 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 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 email addresses.
>
> Urrgh.  RFC 6530 is not an update to 5322.  Don't go there.  I agree there
> is no
> great technical problem sending UTF-8 address strings through EPP.
>
> I'm getting the impression that what we need is a way for the client
> to ask the registry whether it can handle EAI addresses so it knows
> what to accept registrants.  I can imagine a variety of ways to do that.
>
> R's,
> John
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 
>
>

-- 
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Gould, James 
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...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Dmitry Belyavsky 
Date: Monday, October 12, 2020 at 3:59 PM
To: James Gould 
Cc: "jo...@taugh.com" , "Hollenbeck, Scott" 
, "regext@ietf.org" 
Subject: [EXTERNAL] Re: Re: [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-01.txt

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 
mailto:jgo...@verisign.com>> wrote:
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 the EPP greeting and 
login services.  See 
https://tools.ietf.org/html/draft-ietf-regext-secure-authinfo-transfer-03#section-3
 for signaling support for draft-ietf-regext-secure-authinfo-transfer, and see 
https://tools.ietf.org/html/draft-ietf-regext-unhandled-namespaces-03#section-4
 for signaling support for draft-ietf-regext-unhandled-namespaces.

--

JG

[cid:image002.png@01D6A0B3.90BB6A40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: regext mailto:regext-boun...@ietf.org>> on 
behalf of Dmitry Belyavsky mailto:beld...@gmail.com>>
Date: Monday, October 12, 2020 at 3:16 PM
To: John Levine mailto:jo...@taugh.com>>
Cc: "Hollenbeck, Scott" 
mailto:shollenb...@verisign.com>>, 
"regext@ietf.org" 
mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-01.txt

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, 
mailto:jo...@taugh.com>> wrote:
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 email addresses.

Urrgh.  RFC 6530 is not an update to 5322.  Don't go there.  I agree there is no
great technical problem sending UTF-8 address strings through EPP.

I'm getting the impression that what we need is a way for the client
to ask the registry whether it can handle EAI addresses so it knows
what to accept registrants.  I can imagine a variety of ways to do that.

R's,
John

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/lis

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

2020-10-12 Thread Dmitry Belyavsky 
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 EAI via eppEAI namespace, accept in the
 tag

There is also an option "Do nothing, silently accept EAI in the
" which is
implemented in Newstar and TANGO registration systems.

I think we need some consensus to prefer any of these options and I don't
see any options to find out such a consensus than submit a draft and get
some feedback.
Personally, I would prefer either option 2 or option 4.

On Mon, Oct 12, 2020 at 11:20 PM Gould, James  wrote:

> 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
>
>
>
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *Dmitry Belyavsky 
> *Date: *Monday, October 12, 2020 at 3:59 PM
> *To: *James Gould 
> *Cc: *"jo...@taugh.com" , "Hollenbeck, Scott" <
> shollenb...@verisign.com>, "regext@ietf.org" 
> *Subject: *[EXTERNAL] Re: Re: [regext] Fwd: New Version Notification for
> draft-belyavskiy-epp-eai-01.txt
>
>
>
> 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 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 the
> EPP greeting and login services.  See
> https://tools.ietf.org/html/draft-ietf-regext-secure-authinfo-transfer-03#section-3
> 
> for signaling support for draft-ietf-regext-secure-authinfo-transfer, and
> see
> https://tools.ietf.org/html/draft-ietf-regext-unhandled-namespaces-03#section-4
> 
> for signaling support for draft-ietf-regext-unhandled-namespaces.
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com
> 
>
>
>
> *From: *regext  on behalf of Dmitry Belyavsky <
> beld...@gmail.com>
> *Date: *Monday, October 12, 2020 at 3:16 PM
> *To: *John Levine 
> *Cc: *"Hollenbeck, Scott" , "regext@ietf.org" <
> regext@ietf.org>
> *Subject: *[EXTERNAL] Re: [regext] Fwd: New Version Notification for
> draft-belyavskiy-epp-eai-01.txt
>
>
>
> 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 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 email addresses.
>
> Urrgh.  RFC 6530 is not an update to 5322.  Don't go there.  I agree there
> is no
> great technical problem sending UTF-8 address strings through EPP.
>
> I'm getting the impression that what we need is a way for the client
> to ask the registry whether it can handle EAI addresses so it knows
> what to accept registrants.  I can imagine a variety of ways to