ended to be compared to the code points listed in
> Appendix
> B.1. of RFC 5892, it would be better to refer to IDNA Rules and Derived
> Property Values
> <
> https://www.iana.org/assignments/idna-tables-12.0.0/idna-tables-12.0.0.xhtml
> >
> listing the latest IDNA Derived
t been discussed with the WG, why are you revising the
> document at this point rather than withdrawing it from the Last
> Call and review processes?
>
Sorry, but I don't see any changes to the documents other than
clarification/rewording without any significant alterations of th
f.org
https://www.ietf.org/mailman/listinfo/regext
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
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
f.org:
:internet-drafts
___
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
ack, and do you have any additional
> feedback?
> >
> > --
> >
> > JG
> >
> >
> >
> > James Gould
> > Fellow Engineer
> > jgo...@verisign.com
> >
> > 703-948-3271
> > 12061 Bluemont Way
> > Reston, VA 20190
>
8. I believe this addresses your issues. Can you
> > clear your "Ready with Issues" status in the tracker?
> >
> > 1.Delete "It can be an extra ASCII email address collected by
> > registrar or registrar-provided proxy email address." from the
> >
his
diversity is inevitable until countries exist :)
If we try to provide uniform requirements, I'm not sure we should do it via
preventing/limiting usage of non-ASCII email, speaking about this case.
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Dear Patrik,
On Thu, Aug 18, 2022 at 2:23 PM Patrik Fältström wrote:
> On 18 Aug 2022, at 14:14, Dmitry Belyavsky wrote:
>
> > If we try to provide uniform requirements, I'm not sure we should do it
> via preventing/limiting usage of non-ASCII email, speaking about thi
esses or not. Everything else is beyond the
IETF scope.
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Dear John,
Many thanks for your comprehensive response!
On Sun, 21 Aug 2022, 18:24 John C Klensin, wrote:
> Dmitry and James,
>
> I think several different issues are getting intertwined here,
> some of which rise to the level of principles. It is clear that
> we are making different assumpti
Dear John
On Tue, 23 Aug 2022, 04:27 John C Klensin, wrote:
>
>
> --On Monday, August 22, 2022 16:01 + "Gould, James"
> wrote:
>
> > John,
> >
> > How about if we change the approach to use the well-understood
> > command-response extension?
>
> If things were changed to create an extension
-Drafts are also available by rsync at rsync.ietf.org:
:internet-drafts
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
SY, Dmitry Belyavsky
___
regext mailing list
regext
command-response extension, and to replace the EAI references
> > with SMTPUTF8. I believe the remaining issue of the e-mail
> > cardinality needs to be brought back to the REGEXT working
> > group for discussion. I've requested an agenda item at
> > IETF-115 for it and I encourage you to participate in the
> > meeting to discuss it first-hand if the agenda item is
> > accepted.
> >
> > Thank you for all your detailed feedback and discussion!
>
>
>
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
t; 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
> ___
> 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
e document is edited in the
dedicated github repo (https://github.com/beldmit/eppeai). Please
send your submissions via GitHub.
The IETF Secretariat
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailma
Dear Arnt,
On Sun, 6 Aug 2023, 13:39 Arnt Gulbrandsen,
wrote:
> Thursday, 3 August 2023 20:14:41 CEST writes:
> > On Thu, Aug 3, 2023 at 1:23 PM Gould, James wrote:
> >>
> >> So, rollback to draft-ietf-regext-epp-eai-17 with the concept
> >> of a transition period removed and inclusion of "at l
Secretariat
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
GitHub.
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.
The IETF Secretariat
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https
mrmv7bGGtkDxLWyYJufulJaqZILFmfGSMMkAWh07W_JGwcxgQ-FwE5tyXQ_H3Ka6VoeG8BUjpzT77mFSpvxlgcu4il6bYriCZWRrgvLZTH87sUfS2zQ2qIuM-6BHE6xtTxk0J7nbjI8KZUUu9vTJAvq6YnoTNsdf8qPm9KHQ3I-MktA3ikpnptxlzHINmJAIJJPD5L2E/http%3A%2F%2Ftools.ietf.org>
> .
>
> The IETF Secretariat
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *regext on behalf of Dmitry Belyavsky <
> beld...@gmail.com>
> *Date: *Thursday, October 8, 2020 at 10:21 AM
;,
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> 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
submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
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
&
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 N
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
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
>
&
ciated 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
>
any thanks!
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
GDWXBsOnAOQxOjGtERHNpHzKsnKz9ejchOyDdiIlaqfLOg9aQI39btY7z4bJi6U3a8dJUGHQsF3BaGH-zhHPMWB5udn9vylMEQUEcTMCaKu3cxLc6dqGVMeK9VtHspmbya4NZVkqGlGNbK57io7D4HMA6iGFWzfLehh2gyF31-9tcpP59WQRgeWumuRMWqa4wFIqnhKFrCE4R55DBiJjW2iKechIkbUV8fDC-ZkRuiCpXUKMpJgXKnxkmnm_GdnDtwSb4YIME/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
>
> ___
> 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
y consumed by
> other extensions that use email addresses vs. having to also update all
> existing extensions that use email addresses.
>
Adding support of an extension is harder than just allowing EAI email
addresses, both for registries and registrars.
Also, we get some fuz
t having the ASCII ones and some mechanism providing the valid
ASCII email address in the case when such client wants to register a domain
in a registry that does not support EAI.
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://ww
D on turning to RFC: The document is edited in the
dedicated github repo (https://github.com/beldmit/eppeai). Please
send your submissions via GitHub.
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.
On Thu, Nov 19, 2020 at 7:40 PM Mario Loffredo
wrote:
> Hi Dmitry,
>
> should the contact:email element in the response example be set to
> "[EAI-ADDRESS]"?
>
> Best,
>
> Mario
> Il 19/11/2020 17:20, Dmitry Belyavsky ha scritto:
>
> Hello,
>
> I
one, in the long run. But hey, that's
> only my
> > taste.
> > >
> > > Please keep in mind that they're currently an OPTIONAL SMTP extension.
> I
> > think that would need to change before they become a MUST for EPP.
> >
> > I fully agree with Klaus, the proposed extension increases the protocol
> > complexity, adds a lot of job to the EPP software developers, and what it
> > gives back? Less work with the RFCs? Do you really think it is a valuable
> > exchange? And in a new RFC, support of non-ASCII email addresses may be
> > optional.
>
> Sorry, but an extension is a whole lot less complex than changing the core
> protocol.
>
>From my *implementation* experience, the extension (as a body, not just as
a marker) is more complex than relaxing the email syntax.
And we anyway have a much larger volume of work when the registrar starts
tuning his mail system to work with EAI...
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_somehow_.
E.g., they hardly can reject the transfer relying on this reason.
>
> > For example, what would an "old" client do that doesn't understand a
> > potential EAI extension? Would they be deprived of email addres
On Mon, 23 Nov 2020, 21:55 John Levine, wrote:
> In article you write:
> > [SAH] I’m not talking about rejecting a transfer. I’m talking about
> what a registrar that does not support EAI would/should do if
> >it is the receiving registrar of a domain that includes contacts using
> internation
submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
://github.com/beldmit/eppeai). Please
send your submissions via GitHub.
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.
The IETF Secretariat
--
SY, Dmitry Belyavsky
Dr. Mario Loffredo
>
> > Technological Unit “Digital Innovation”
>
> > Institute of Informatics and Telematics (IIT)
>
> > National Research Council (CNR)
>
> > via G. Moruzzi 1, I-56124 PISA, Italy
>
> > Phone: +39.0503153497
>
> > Web: http:
gt;> >> Your REGEXT co-chairs Jim and Antoin
>>
>> >> _______
>>
>> >> regext mailing list
>>
>> >> regext@ietf.org
>>
>> >> https:
www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______
> regext mailing list
> regext@ietf.org
> https://www.ietf.o
valid address may be required) and
policy stuff (that imply the EAI addresses should be treated as just email
addresses).
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
only registry must support the EAI also the
> registrar have to do it.
>
Yes. But, if a registrar can't access the registrant via EAI email, the
registrant will be able to chose another registrar - of course, if the
registry supports such addresses.
>
> Regards
> Marco
>
at subject.
>
>
Thanks for your letter!
Let me remind you that the 1st version of the draft proposed an update to
basic schemas to indicate that EAI addresses are valid.
I like your proposal about redesigning the client schema, but I'd also
remind that Contact is not the only objec
Dear Patrick,
On Mon, Aug 2, 2021 at 8:40 PM Patrick Mevzek wrote:
> On Mon, Aug 2, 2021, at 12:17, Dmitry Belyavsky wrote:
> > Let me remind you that the 1st version of the draft proposed an update
> > to basic schemas to indicate that EAI addresses are valid.
>
> Yes, but
www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______
> regext mailing list
> regext@ietf.org
> https://www.ietf.o
>
>
> Thanks,
>
> Jody Kolker
>
> GoDaddy
>
>
> ___
> 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
actions for each semantic (i.e., no data or EAI).
>
>
>
> I think that the action for this case (EAI persisted for an optional
> field) should be as in the case where the email property is required, in
> other words, to return the error code 2308.
>
>
>
> Thoughts?
&
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _____
t-ietf-regext-epp-eai-04.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-04
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _____
someone or I will volunteer to handle your
> document. Expect an outreach from the Chairs shortly after this message.
>
> The IETF data tracker will announce this meeting shortly, as soon as I get
> can get it entered in to the system.
>
> Thanks all!
>
> Jim
>
> __
regext-epp-eai-05
Internet-Drafts are also available by rsync at rsync.ietf.org:
:internet-drafts
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
SY, Dmitry Belyavsky
y6vGMyLePNyeha5aFXPg4jY4xpuRq6VNGzbMIeeqg
> > nw_yTHAPZV7tlWCeAbhXEwUg21MetU8GFuFV_5mqGR1qrC6TFuY6K_1tBuh
> > nlPECh2n-58RY1QH4ZTK6flKyNwxX_K-
> > gmeWvGtkCC4L8Zp4S04w5J2e3AczYPujFUpZP03fjW3BMjBOkt_vM2Sk5D_s/
> > https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
> ___
> 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
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
> >&
On Sat, Dec 18, 2021 at 2:53 PM Taras Heichenko
wrote:
>
>
> > On 15 Dec 2021, at 16:14, Dmitry Belyavsky wrote:
> >
> > Dear Taras.
>
> Dear Dmitry
>
> >
> > On Tue, Dec 14, 2021 at 8:13 PM Taras Heichenko
> wrote:
> > The comment is i
__
> 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
-drafts
___
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 usability errors."*
>
>
>
> *The IANA Considerations section still uses “eai-0.3”. It should be
> “eai-1.0”.*
>
>
>
> *Scott*
> ___
> 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
The document shepherd for this document is Jody Kolker.
> Jody, when you have done your review, please let us know the result.
> When there were no substantive changes during WGLC, you can start the
> shepherd writeup for version 06.
>
> Regards,
>
> Jim and Antoin
>
&g
support such email addresses.
TO BE REMOVED on turning to RFC: The document is edited in the
dedicated github repo (https://github.com/beldmit/eppeai). Please
send your submissions via GitHub.
The IETF Secretariat
--
SY, Dmitry Belyavsky
Dear colleagues,
Sorry, I missed the original letter to the ML.
I'm not aware of any IPR from my side.
If it matters, in this area I consider myself as an independent
software developer, with no relationship to any company.
--
SY, Dmitry Bely
rsync.ietf.org::internet-drafts
___
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
above, I’ll submit the Shepard
> Document.
>
>
>
> Please let me know if you have any questions.
>
>
>
> Thanks Everyone!
>
>
>
> Jody Kolker
>
>
>
> _______
> regext mailing list
> regext@ietf.org
> h
I will submit the Shepard Document once we have sign off from James Gould
> regarding IPR; unless I have missed that email (which is entirely possible)?
>
> Thanks,
> Jody Kolker.
>
> -Original Message-
> From: regext On Behalf Of Dmitry Belyavsky
> Sent: Mond
ding to IDNA2008 [RFC5892]"
>
> 4) You might want to say something explicit about all of the EAI security
> issues also applying to this work.
>
We have pretty well described security considerations in RFCs 6530 and
6531. I think referring to them is a good option. I don't
epp-eai-09
Internet-Drafts are also available by rsync at rsync.ietf.org:
:internet-drafts
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
SY, Dmitry Belyavsky
___
rege
Dear Murray,
Done, many thanks!
On Sun, May 22, 2022 at 7:51 AM Murray S. Kucherawy
wrote:
> On Fri, May 20, 2022 at 6:08 AM Dmitry Belyavsky
> wrote:
>
>> On Tue, May 17, 2022 at 7:28 PM Murray S. Kucherawy
>> wrote:
>>
>>> 1) In Section 3, you have:
>
g/rfcdiff?url2=draft-ietf-regext-epp-eai-10
Internet-Drafts are also available by rsync at rsync.ietf.org:
:internet-drafts
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
in advance for the successful transfer.
>
> Many thanks for your review!
Yes, transfer becomes impossible in such situations, but the operational
practices are beyond the scope of this document.
It's more a matter of, say, ICANN recommendations.
--
SY, Dmitry Belyavsky
__
quired
> email property, since the info response will result in an error. It should
> be a MUST as well. The error response is a MUST in the fourth bullet.
>
I replaced both these SHOULDs with MUST
>
> Nits/editorial comments:
>
> Abstract: Strike the word "appe
nal
> > email property falls the same case as the required email
> > property, since the info response will result in an error. It
> > should be a MUST as well. The error response is a MUST in the
> > fourth bullet.
>
> It seems to me that what you ju
dedicated github repo (https://github.com/beldmit/eppeai). Please
send your submissions via GitHub.
The IETF Secretariat
--
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/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
ight have.
>
> Since I've been critical about some aspects of older revisions, I'll just
> state for the record that I'm happy about publishing this. Thanks Scott and
> others.
I would be happy about publishing it. We have tried several
approaches, if this one works
75 matches
Mail list logo
