On Sat, Dec 18, 2021 at 2:53 PM Taras Heichenko <ta...@academ.kiev.ua> wrote:
> > > > 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? > I don't see it will be contrary, and so I don't think we need to specify this in this document. BTW, I've already removed the phrases about extra email limitations. > > > > > > > > > >> 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 > > > > > > -- SY, Dmitry Belyavsky
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
