> On 15 Dec 2021, at 16:14, Dmitry Belyavsky <beld...@gmail.com> wrote:
>
> Dear Taras.
Dear Dmitry
>
> On Tue, Dec 14, 2021 at 8:13 PM Taras Heichenko <ta...@academ.kiev.ua> wrote:
> The comment is in body.
>
> > On 13 Dec 2021, at 15:15, Hollenbeck, Scott
> > <shollenbeck=40verisign....@dmarc.ietf.org> wrote:
> >
> >> -----Original Message-----
> >> From: Gould, James <jgould=40verisign....@dmarc.ietf.org>
> >> Sent: Thursday, December 9, 2021 11:59 AM
> >> To: Hollenbeck, Scott <shollenb...@verisign.com>;
> >> ietf=40antoin...@dmarc.ietf.org <i...@antoin.nl>; regext@ietf.org
> >> Subject: [EXTERNAL] Re: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-
> >> eai-04
> >>
> >> Caution: This email originated from outside the organization. Do not click
> >> links
> >> or open attachments unless you recognize the sender and know the content
> >> is safe.
> >>
> >> Scott,
> >>
> >> Thanks for the review and feedback. I provide responses to your feedback
> >> embedded below.
> >>
> >> --
> >>
> >> 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://secure-
> >> web.cisco.com/1bUEhaRz5CoSQPd4colm8eTGE5D6zPQvtrYPAzQf9pUSXnqD
> >> Nq7mmnlZ8At92joPzY5DkJdQiiPe1mlyvgzDAdDz_shcqHzSugkfXA2qX9z7aQp0
> >> 6ld-
> >> LnwMzxo2VGkwqFH5gLrI7qSYQlgj4Unll4AIUd6ALSZ38i2kjYqgA0AnBBjaJEVg7
> >> yUIN-
> >> P8bpFGxQgN__tWour_sxUBBx2vUcVpmrR7SUG6UsUo5U3gb_YbWCYcRn8b
> >> 4Rl06BQIL8B8k/http%3A%2F%2Fverisigninc.com%2F>
> >>
> >> On 12/6/21, 9:18 AM, "regext on behalf of Hollenbeck, Scott" <regext-
> >> boun...@ietf.org on behalf of shollenbeck=40verisign....@dmarc.ietf.org>
> >> wrote:
> >>
> >>
> >> A few questions/comments:
> >>
> >> Section 6: We need to provide the rationale for that SHOULD (Registries
> >> SHOULD validate the domain names in the provided email addresses). What
> >> does "validate" mean? For syntax? For reachability?
> >>
> >> JG - This is associated with validating the syntax. The goal is to ensure
> >> that
> >> the domain name, whether an ASCII or IDN domain name is a syntactic valid
> >> domain name the may be reachable. Would it help to modify this to read
> >> "Registries SHOULD validate the syntax of the domain names in the provided
> >> email addresses so they may be reachable."?
> >
> > [SAH] Syntax validity is no guarantee of reachability. The only way to
> > confirm
> > that an email address "works" is to send email to that address and confirm
> > that it's delivered. I don't think we want to suggest that registries
> > should
> > start sending out email delivery tests, so maybe something like this
> > instead:
> >
> > " Registries SHOULD ensure that the provided email addresses are
> > syntactically
> > valid to reduce the risk of future usability errors."
>
> The check of existing of the domain (MX or at least A/AAAA record) from the
> email address may be added. I am not sure that it should be there but it also
> raises the probability that the email address is valid.
>
> Personally I don't think it is feasible to reject the contact
> registration/change if these records don't exist.
> And anyway, it's out of scope for this document.
I just wanted to say that there are different ways to check the validity of an
email address.
If some registry does such a check will it be contrary to the RFC? May we need
a phrase that
allows wider Interpretation?
>
>
> >
> >> Section 7: What's significant about "eai-0.3"? The "0.3" part doesn't
> >> track to
> >> the current version of the draft; perhaps "1.0" would be better now. See
> >> also
> >> Section 5.2.
> >>
> >> JG - Yes, the namespace will be changed to "eai-1.0" once it passes WGLC
> >> similar to what has happened in past EPP extensions with pointed
> >> namespaces.
> >
> > [SAH] OK.
> >
> >> Section 8: It might be helpful to add more text to explain why
> >> "Registries
> >> MAY apply extra limitation to the email address syntax". Why might they
> >> want to do that? It seems a little unusual to say that they MAY do
> >> something,
> >> but in the next sentence say, "These limitations are out of scope of this
> >> document".
> >>
> >> JG - Agreed, this does not look to add value. Do you believe the
> >> Implementation Considerations section should be removed, since the
> >> contents really don't provide any material considerations?
> >
> > [SAH] Yes, that's probably a good idea.
> >
> > Scott
> > _______________________________________________
> > regext mailing list
> > regext@ietf.org
> > https://www.ietf.org/mailman/listinfo/regext
>
> --
> Taras Heichenko
> ta...@academ.kiev.ua
>
>
>
>
>
> _______________________________________________
> 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
--
Taras Heichenko
ta...@academ.kiev.ua
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
