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

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
<contact:email> tag
3. Indicate accepting EAI via eppEAI namespace, accept in the
<contact:email> tag
4. Indicate accepting EAI via eppEAI namespace, accept in the
<someext:email> tag

There is also an option "Do nothing, silently accept EAI in the
<contact:email>" 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 <jgould@verisign.com> 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
> jgould@Verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *Dmitry Belyavsky <beldmit@gmail.com>
> *Date: *Monday, October 12, 2020 at 3:59 PM
> *To: *James Gould <jgould@verisign.com>
> *Cc: *"johnl@taugh.com" <johnl@taugh.com>, "Hollenbeck, Scott" <
> shollenbeck@verisign.com>, "regext@ietf.org" <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 <jgould@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
> <https://secure-web.cisco.com/1kbbME8WxKH25Af398m-OdqUFjso557LWijQiFXQJ0UKuX4cZCZzvDbYaHCY2_clcdljSgNx33sKFt3KGtedibBS3rd7Wn-tjukLzyRje6FwtvocFZuU1taYezRymzvBZLrldkbICauhkSsHRwazoFoHJepPRC6Q29CN67WEfGRnRBhURM55BobSdxDlos3bzBjeAVgNZ2oo3W_D3k7qndME5v-P8RlGiMBYYOnHXTBW6lDhznLqy1qBTvRiOl1ikEZMFhPPlvc7CdrjXu9iJcjMbQnUP7KNOmkd3ipkG-p0/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-secure-authinfo-transfer-03%23section-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
> <https://secure-web.cisco.com/1fDC9N8uU6IPT_EF_7uAAVznUD8SeRiQfEspxbZ7K462x3pUcWXANQLl65DhwDm42Tnzst5sWdgJoVVwVaV1nwfEeLIyJ84n7hf0no3KNDmr2FSnfWqoUXwz7CcJKtVHxVeqCPxPrSAtXLVXqMNxyXq43d3XwpQocebl_3CR6r5qfOs6MYXycUvkWQIrUmoVDWKVBZrlAb2X9LGj-xHMMzptz9EHkzj73LblhoBU1TlzhwfEE7NZvB629ZmMF3aDzE-uj8tBvwsCTWyPC2vNVAorS3uKjIAJx0Y5lZgMXKV4/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-unhandled-namespaces-03%23section-4>
> for signaling support for draft-ietf-regext-unhandled-namespaces.
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> jgould@Verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com
> <http://secure-web.cisco.com/1Itq6Iu9Ce3lRF7_uiaHCucQVya2sg9-ft8Yg6yP0k3-0H1E8iw8Qqmyc31A7wscCr2uY1m-HhwBC5gY9_wQA6GqtaTqqrdWBFlmQbZhx9-EAmD7vYlV5mMkhJwoXIx70fLtS0dHUPlEdGFEPd9k-L5bRtUyRqdp3eV4jrrKZmQfZ4WjKC2Jy8jEh_kWBRrtR_-uXI1DFtzyn2ZmPQoNRfbEYvr-RfL16Esuwi_20hlASRB2BwJchik4sDeE8emLBSZjWDtN4v-s8j7MFzMbKhg/http%3A%2F%2Fverisigninc.com%2F>
>
>
>
> *From: *regext <regext-bounces@ietf.org> on behalf of Dmitry Belyavsky <
> beldmit@gmail.com>
> *Date: *Monday, October 12, 2020 at 3:16 PM
> *To: *John Levine <johnl@taugh.com>
> *Cc: *"Hollenbeck, Scott" <shollenbeck@verisign.com>, "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, <johnl@taugh.com> wrote:
>
> In article <542572b0e6284550a9bee035bea2d6bf@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
> <https://secure-web.cisco.com/1E2O9BAxjfPFRfBkfkdxxMTw4FeUHvpkoq0D8pXADkch3J8zQcnJFteI9-DnviuVEI5t6W5sTnonl8zXd9JKRrx-gGoGyQXdMImvWtBZf9dYNpujyBnEMqxC1Ly9rBkcppwn1Q8waImJkzHzgPSR5W076Bq_Qj1fvERIlfLyfP1t5QgoTwZ2gpmuX85-A2Z_DzpzUdNJ-F5_W-JNHhs7NJcXcs3bEciqsCWn8Pogs9sG9e5TijoAKpJc7gqcV6DlHoJghQ11jLtbMvnQ48zpr3_uROAOzByjqHEoLAyKKmWY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>

-- 
SY, Dmitry Belyavsky

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

Attachment: image001.png

Attachment: image002.png