Hi All, I’m glad that my bad phrasing at least got some action into this discussion. I didn’t mean to say that we can’t have 2 standards, but we should at least have clarity on the status of this document. Because the original document title was "jcard-deprecation <https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-jcard-deprecation/>", and the introduction still talks about the intent and transition mechanisms to replace jCard, we can be a bit clearer that jsContact is a second standard, at least until jCard can be deprecated from support in RDAP after jsContact is sufficiently supported.
When we all agree jsContact is a second standards track document not intended to deprecate jCard just yet today, then that’s fine. If we don’t get feedback this document should have a different status than standards track, then the chairs will add that intended status next week. Which leaves the remaining questions Mario posted in his original message. - -- Antoin Verschuren > Op 8 dec. 2021, om 14:53 heeft Gould, James > <jgould=40verisign....@dmarc.ietf.org> het volgende geschreven: > > I view the jscontact is a valid use case for a standards track RDAP > extension. We have many similar use cases for standards track extensions in > EPP, where the RFCs couldn't envision a feature or an approach that comes up > later. The jscontact draft needs to be defined as an RDAP extension that is > optional, with the appropriate signaling, and with transition considerations > to support a transition from the jCard defined in RFC 9083 to JSContact > defined in the extension. I don't foresee that support for jCard will go > away, but that JSContact can be become an alternative and potentially a > preferred format for the RDAP contact data. As Scott points out, supporting > multiple formats can add complexity, but I believe that is a known cost to > progress. > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com <mailto:jgo...@verisign.com> > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisign.com/> <http://verisigninc.com/ > <http://verisigninc.com/>> > > On 12/8/21, 5:31 AM, "regext on behalf of Gavin Brown" > <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of > gavin.br...@centralnic.com <mailto:gavin.br...@centralnic.com>> wrote: > > > On 8 Dec 2021, at 09:55, Mario Loffredo <mario.loffr...@iit.cnr.it > <mailto:mario.loffr...@iit.cnr.it>> wrote: >> >> >> >> Il 07/12/2021 14:42, Marc Blanchet ha scritto: >>> >>>> Le 7 déc. 2021 à 08:35, Hollenbeck, Scott >>>> <shollenbeck=40verisign....@dmarc.ietf.org >>>> <mailto:shollenbeck=40verisign....@dmarc.ietf.org>> a écrit : >>>> >>>> We can *certainly* do that, Mario. It’s the option I support because there >>>> is a cost to replace a jCard implementation once it’s been implemented and >>>> deployed. Make it an optional extension and let server operators decide >>>> if/when they want to make the change. >>>> >>>> I note that this will make life more difficult for client implementors >>>> because they’ll have to support both formats. >>> >>> But the genie is already out of the bottle… I.e. if one have done a client >>> implementation, it has already support for jCard. Adding the JSContact is >>> just more code. There will be only less work if one is implementing a >>> client in the future after the whole ecosystem had moved to JSContact, >>> therefore no need to implement jCard, which is still a good win, as I guess >>> that many haven’t implemented a client yet since whois is still dominant >>> and RDAP is not yet at the same level. >> +1 >> >> Every extension requires an implementation effort and every transition >> process from the old to the new requires a period where both coexist. >> >> If we hadn't been aware of that, we wouldn't have started the process to >> replace Whois with RDAP. And, like Marc pointed out, this process is still >> at the beginning and we still don't imagine when it will really be >> completed. >> >> In addition to that, I wonder why some members are so worried about the >> implementation effort done in this case in comparison to other extensions >> that completed the reviewing process. > > Speaking as a client implementer, the amount of work required to update my > RDAP client to support JSContact was minimal - which speaks to how much > easier JSContact is to work with than jCard. You can see every change > required in https://client.rdap.org <https://client.rdap.org/> here: > > > https://secure-web.cisco.com/1_Pf0XRu1tk3UR9-6jZ90CvItjm2neWOUbvFQlelz4q63NRctDM-rSfl0bSRaAV5EIV9aE7ka0U0or5uuTlvu68I6aSE7VnsWBMFLUFRToK6mDmJVHxBBFK9ztDZYSfxcAMaVmIUkFCaAOHPItTkzGJXFdCLs60lPUJp2yLiotBDfMlMsuDyuTUll6Ztrs4m3Vj8YoUgfwCkcXc0kxZzpigQikmbW3FGPQi8p2bgQ2NvJay4AkRznJp9CFRCj47UD/https%3A%2F%2Fgitlab.centralnic.com%2Fcentralnic%2Frdap-web-client%2F-%2Fcompare%2Fba4fd514...c9deae03 > > <https://secure-web.cisco.com/1_Pf0XRu1tk3UR9-6jZ90CvItjm2neWOUbvFQlelz4q63NRctDM-rSfl0bSRaAV5EIV9aE7ka0U0or5uuTlvu68I6aSE7VnsWBMFLUFRToK6mDmJVHxBBFK9ztDZYSfxcAMaVmIUkFCaAOHPItTkzGJXFdCLs60lPUJp2yLiotBDfMlMsuDyuTUll6Ztrs4m3Vj8YoUgfwCkcXc0kxZzpigQikmbW3FGPQi8p2bgQ2NvJay4AkRznJp9CFRCj47UD/https%3A%2F%2Fgitlab.centralnic.com%2Fcentralnic%2Frdap-web-client%2F-%2Fcompare%2Fba4fd514...c9deae03> > > Getting JSContact working in the CentralNic RDAP server took a bit more > work, but I see it as being worthwhile if it makes life easier for client > implementers. > > We are still in the early days of RDAP, and the amount of RDAP code that > exists now is much smaller than the amount of RDAP code still to be written. > If we can make a modest change now that makes that future code smaller and > easier to write and maintain, we should do so. > > (full disclosure: I am a co-author on this draft). > > G. > >> >> For example, why haven't we been so concerned about the implementation >> effort required to client and servers in order to implement the EPP Login >> Security extension and the consequent period where clients and servers >> should deal with both the password formats ? And what about the >> implementation effort done to replace custom solutions already existing with >> new standard solutions? >> >> Honestly, it seems to me that the implementation effort required in this >> case is lower than the one required by other extensions. >> >> I believe that the main point is if we (intended as most of us) finally >> agree that the benefits from implementing an extension far outweigh the >> required efforts and we have evidence that >> >> the new will be significantly better than the old (and it seems to me we >> have it in this case). >> >> But, at the same time, we are not sure that the majority of EPP or RDAP >> operators will implement it. That's it. >> >> >> >> >> That being said, IMO, the status of this document should remain "Standard >> Track". > > +1 > >> >> >> >> Best, >> >> Mario >> >>> >>>> “Be liberal in what you accept” applies. >>> >>> yes. >>> >>> Marc. >>> >>>> >>>> Scott >>>> >>>> From: regext <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>> On >>>> Behalf Of Mario Loffredo >>>> Sent: Tuesday, December 7, 2021 3:45 AM >>>> To: Antoin Verschuren <ietf=40antoin...@dmarc.ietf.org >>>> <mailto:ietf=40antoin...@dmarc.ietf.org>>; regext@ietf.org >>>> <mailto:regext@ietf.org> >>>> Subject: [EXTERNAL] Re: [regext] New Version Notification for >>>> draft-ietf-regext-rdap-jscontact-04.txt >>>> >>>> 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. >>>> >>>> Hi all, >>>> >>>> maybe I'm missing something but is there anybody explaining me why we can >>>> have two standards for the email address in EPP but we cannot have two >>>> standards for the contact card in RDAP ? >>>> >>>> I admit that the reasons supporting the two documents are different but >>>> their matters appear very similar to me. >>>> >>>> Using JSContact inside RDAP is basically an extension. >>>> >>>> If we remove stages 3 and 4 of the transition from the document, we simply >>>> have an RDAP extension that is or isn't implemented by a server. >>>> >>>> This extension can be firstly signaled by the server, then requested by >>>> the client and consequently returned by the server just as it happens for >>>> the EAI extension in the EPP context. >>>> >>>> >>>> >>>> Best, >>>> >>>> Mario >>>> >>>> >>>> >>>> Il 06/12/2021 15:29, Antoin Verschuren ha scritto: >>>> Hi all, >>>> >>>> In addition to the questions from Mario, we still need to discuss the >>>> status of this document as discussed during the IETF112 meeting: >>>> >>>> "the document doesn’t have designated status; it was adopted without a >>>> status (on purpose). We need to think about the implications. Encouraged >>>> group to discuss/comment on the list” >>>> >>>> Meaning that because jCard is not depreciated with publishing this >>>> document, what will the status of this document be? We cannot have 2 >>>> standards, so we need to say something about it. >>>> >>>> Jim and Antoin >>>> >>>> >>>> >>>> Op 27 nov. 2021, om 09:04 heeft Mario Loffredo <mario.loffr...@iit.cnr.it >>>> <mailto:mario.loffr...@iit.cnr.it>> het volgende geschreven: >>>> >>>> Hi folks, >>>> this new version addresses the feedback provided by Jasdip except for the >>>> following two points left for WG discussion: >>>> 1) In the sentence "To aid interoperability, RDAP providers are >>>> RECOMMENDED to use as map keys the following string values and labels >>>> defined in [RFC5733].", should "are RECOMMNEDED >>>> to" be replaced with "MUST"? >>>> 2) Does the portion of the spec for jCard to JSContact transition >>>> signaling add significant implementation overhead for RDAP servers and >>>> clients? Could an out-of-band (OOB) method have been employed? >>>> >>>> Three more implementations were included. >>>> >>>> Best, >>>> Mario >>>> >>>> >>>> -------- Messaggio Inoltrato -------- >>>> Oggetto: >>>> New Version Notification for draft-ietf-regext-rdap-jscontact-04.txt >>>> Data: >>>> Fri, 26 Nov 2021 23:53:34 -0800 >>>> Mittente: >>>> internet-dra...@ietf.org >>>> A: >>>> Gavin Brown <gavin.br...@centralnic.com>, Mario Loffredo >>>> <mario.loffr...@iit.cnr.it> >>>> >>>> >>>> >>>> A new version of I-D, draft-ietf-regext-rdap-jscontact-04.txt >>>> has been successfully submitted by Mario Loffredo and posted to the >>>> IETF repository. >>>> >>>> Name: draft-ietf-regext-rdap-jscontact >>>> Revision: 04 >>>> Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON >>>> Responses >>>> Document date: 2021-11-26 >>>> Group: regext >>>> Pages: 22 >>>> URL: >>>> https://secure-web.cisco.com/1uQaV0-jKtv71LGZlehOyaCbEn5S_Ja8HUolF3Idzs0e_X6-FOVJo79ccBlXhH8Pa8WvTzUORi1a4SnzxhrQs9woY7UjWIOVqZPWMMunD7Bcq-tk4w7ZBo0KaQJamS2bsqxpinoIQrlih28J7rvcPOJvt5q3ipkkJrjPDHmTGMLqO4pbwQKGB6A0GhAYFY9okn0vW4vpToNQYDmzNZzOP55THKmNPeTVzrti-rjdlQTOCYfeZM51CaTqCyLt6YIw5/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-jscontact-04.txt >>>> >>>> <https://secure-web.cisco.com/1uQaV0-jKtv71LGZlehOyaCbEn5S_Ja8HUolF3Idzs0e_X6-FOVJo79ccBlXhH8Pa8WvTzUORi1a4SnzxhrQs9woY7UjWIOVqZPWMMunD7Bcq-tk4w7ZBo0KaQJamS2bsqxpinoIQrlih28J7rvcPOJvt5q3ipkkJrjPDHmTGMLqO4pbwQKGB6A0GhAYFY9okn0vW4vpToNQYDmzNZzOP55THKmNPeTVzrti-rjdlQTOCYfeZM51CaTqCyLt6YIw5/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-jscontact-04.txt> >>>> Status: >>>> https://secure-web.cisco.com/1W_ZuCoeBQhlTAUM5Z4ZRKIx4K4jKuM1qJmBOKp5AeZk08Q1SxXm-qT_tC8nx1df8B4MjwdiE6nSQoTqiDxRNprsFJiPNDME0adRxhA48D6EAVpmf-tkCz5bUXAADdgF6CoWqR6WxYFZmGo0KRa2we7JFlk50h-ctdzsZUjT0nODUALd0zPW4yJCJTvw4iLkaJpOSNC2eYsyl5AiC3sWSkwfi4aJCpDrrUs8nTOdLRH77boJLF-mKuuJxiNwoBQ1B/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-jscontact%2F >>>> >>>> <https://secure-web.cisco.com/1W_ZuCoeBQhlTAUM5Z4ZRKIx4K4jKuM1qJmBOKp5AeZk08Q1SxXm-qT_tC8nx1df8B4MjwdiE6nSQoTqiDxRNprsFJiPNDME0adRxhA48D6EAVpmf-tkCz5bUXAADdgF6CoWqR6WxYFZmGo0KRa2we7JFlk50h-ctdzsZUjT0nODUALd0zPW4yJCJTvw4iLkaJpOSNC2eYsyl5AiC3sWSkwfi4aJCpDrrUs8nTOdLRH77boJLF-mKuuJxiNwoBQ1B/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-jscontact%2F> >>>> Htmlized: >>>> https://secure-web.cisco.com/1Cx_B5RCTVwDAOt-QueJSoDp-xCQRSwYHOs3GoOtvUod_GALzjZbsE8G709DjYM10Ov8nGy4cFBWN3Lab20GfYe5tHFGy1pEEWXlt-PphwRDAt4BeFbP7JZAuzLh_MpFzyjeH2n-VK76nVNke2vzRLycvn_8zKBdNDZIObxdVSaPcesu0y8AXiid_qroZDoq6XFetaOmahdPzI4bg_fCPAoAJGpIoZmkOPi26F4sNiWZ9ESYHiqkjJqYzdXKkryBn/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-jscontact >>>> >>>> <https://secure-web.cisco.com/1Cx_B5RCTVwDAOt-QueJSoDp-xCQRSwYHOs3GoOtvUod_GALzjZbsE8G709DjYM10Ov8nGy4cFBWN3Lab20GfYe5tHFGy1pEEWXlt-PphwRDAt4BeFbP7JZAuzLh_MpFzyjeH2n-VK76nVNke2vzRLycvn_8zKBdNDZIObxdVSaPcesu0y8AXiid_qroZDoq6XFetaOmahdPzI4bg_fCPAoAJGpIoZmkOPi26F4sNiWZ9ESYHiqkjJqYzdXKkryBn/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-jscontact> >>>> Diff: >>>> https://secure-web.cisco.com/1__y1AKzAWuKGNWrnDe1VzsI7jBkHbv-zIQJRkstV46WKKjLnIPWqu3L8brOPX9PsHJQQRBSTTRPlhh5rkFYg9alryyCc7HKf2TDH9wtlV6v7SmYP1vp9OjLBNITEz1J5dLVJoYpdD5-uErtfV9fuHTsY-zXDBi9b7f_zH_OwFkuz9weCyN7xw1shHH4GgfaGi5L2jwSG-eiz9DdcgeY64p9QRb1xWgHVEgNOvyzX6XwX-o8PoZg-rCwCqIqDm8PR/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-rdap-jscontact-04 >>>> >>>> <https://secure-web.cisco.com/1__y1AKzAWuKGNWrnDe1VzsI7jBkHbv-zIQJRkstV46WKKjLnIPWqu3L8brOPX9PsHJQQRBSTTRPlhh5rkFYg9alryyCc7HKf2TDH9wtlV6v7SmYP1vp9OjLBNITEz1J5dLVJoYpdD5-uErtfV9fuHTsY-zXDBi9b7f_zH_OwFkuz9weCyN7xw1shHH4GgfaGi5L2jwSG-eiz9DdcgeY64p9QRb1xWgHVEgNOvyzX6XwX-o8PoZg-rCwCqIqDm8PR/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-regext-rdap-jscontact-04> >>>> >>>> Abstract: >>>> This document describes an RDAP extension which represents entity >>>> contact information in JSON responses using JSContact. >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>>> _______________________________________________ >>>> regext mailing list >>>> regext@ietf.org <mailto:regext@ietf.org> >>>> https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >>>> >>>> <https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> >>>> >>>> >>>> >>>> _______________________________________________ >>>> regext mailing list >>>> regext@ietf.org <mailto:regext@ietf.org> >>>> https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >>>> >>>> <https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> >>>> -- >>>> 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://secure-web.cisco.com/1xIJoQsdiqp7TXVZSFzGEv8YUUvMoNSA3xaMYxkUI-7W8J25Bgr_Q7kvU04yiMB5aMxRncUD_XuByVtVf40IgGbgUKStfdITYBlOn9XJGHggHoNU13YTUMVK7Un4qI-4fnvZ-iqewk7VhgipQTtrIP9YQT5OE0sP7dhHtS3vkMuean0twqDZkeTWdAeplpoiFQDyLKIm4ZCE0vWNM5_UPH7Cy_q0PuU3hfEcXXguCSKYRGsFNavPifomzaHAJ4Kb7/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo >>>> >>>> <http://secure-web.cisco.com/1xIJoQsdiqp7TXVZSFzGEv8YUUvMoNSA3xaMYxkUI-7W8J25Bgr_Q7kvU04yiMB5aMxRncUD_XuByVtVf40IgGbgUKStfdITYBlOn9XJGHggHoNU13YTUMVK7Un4qI-4fnvZ-iqewk7VhgipQTtrIP9YQT5OE0sP7dhHtS3vkMuean0twqDZkeTWdAeplpoiFQDyLKIm4ZCE0vWNM5_UPH7Cy_q0PuU3hfEcXXguCSKYRGsFNavPifomzaHAJ4Kb7/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> >>>> _______________________________________________ >>>> regext mailing list >>>> regext@ietf.org <mailto:regext@ietf.org> >>>> https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >>>> >>>> <https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> >>> >>> >>> >>> _______________________________________________ >>> regext mailing list >>> >>> regext@ietf.org <mailto:regext@ietf.org> >>> https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >>> >>> <https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> >> -- >> 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://secure-web.cisco.com/1xIJoQsdiqp7TXVZSFzGEv8YUUvMoNSA3xaMYxkUI-7W8J25Bgr_Q7kvU04yiMB5aMxRncUD_XuByVtVf40IgGbgUKStfdITYBlOn9XJGHggHoNU13YTUMVK7Un4qI-4fnvZ-iqewk7VhgipQTtrIP9YQT5OE0sP7dhHtS3vkMuean0twqDZkeTWdAeplpoiFQDyLKIm4ZCE0vWNM5_UPH7Cy_q0PuU3hfEcXXguCSKYRGsFNavPifomzaHAJ4Kb7/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo >> >> <http://secure-web.cisco.com/1xIJoQsdiqp7TXVZSFzGEv8YUUvMoNSA3xaMYxkUI-7W8J25Bgr_Q7kvU04yiMB5aMxRncUD_XuByVtVf40IgGbgUKStfdITYBlOn9XJGHggHoNU13YTUMVK7Un4qI-4fnvZ-iqewk7VhgipQTtrIP9YQT5OE0sP7dhHtS3vkMuean0twqDZkeTWdAeplpoiFQDyLKIm4ZCE0vWNM5_UPH7Cy_q0PuU3hfEcXXguCSKYRGsFNavPifomzaHAJ4Kb7/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> > > -- > Gavin Brown > Head of Registry Services > CentralNic Group plc (LSE:CNIC) > > https://secure-web.cisco.com/1jdq3DW0oaBcuR8g7MK_IAFftZoi9qNQONY2gbBkcdtkzdjgpDNfAwYhCiPXpzLJx7HXceBvuSlI_YmyAn4hM1OtmSzGtnkvhT7wTNN-A1uf1diCSDeMC34FjGmy4-gX_nzIyAgYI1aBek26Xy4yD9s4tM4zavbIJoxuOUNW1B-wh4eTwoZapI_RokIhaWWC2HwMDBlXqYBH66u-ZBms7vWKubbJ_g-YAiph8xJTCNzw1U155bn-_zQkjygvnJHS_/https%3A%2F%2Fcentralnicregistry.com > > <https://secure-web.cisco.com/1jdq3DW0oaBcuR8g7MK_IAFftZoi9qNQONY2gbBkcdtkzdjgpDNfAwYhCiPXpzLJx7HXceBvuSlI_YmyAn4hM1OtmSzGtnkvhT7wTNN-A1uf1diCSDeMC34FjGmy4-gX_nzIyAgYI1aBek26Xy4yD9s4tM4zavbIJoxuOUNW1B-wh4eTwoZapI_RokIhaWWC2HwMDBlXqYBH66u-ZBms7vWKubbJ_g-YAiph8xJTCNzw1U155bn-_zQkjygvnJHS_/https%3A%2F%2Fcentralnicregistry.com> > > Cal: http://cnic.link/gbcalendar <http://cnic.link/gbcalendar> > > CentralNic Group plc is a company registered in England and Wales with > company number 8576358. Registered Offices: Saddlers House, Gutter Lane, > London EC2V 6BR. > > > https://secure-web.cisco.com/13-E0oRnwyeA8SenfNfBy4KMSGtCic3FVW1vcuJDPs9XkobKDsEK0YgbQpenao1bT_oCMeSL8v7X7dPPo_gFf_bXkz8tTZU92gvbXuBLb478kPPRkPRaJii-ywI_5V6zzMjROQ4O6fCkU2zeI5OntXAtYcD9BSWMQJAnDjXel6jy_Gli1quLEb9mnco30J8Uq_pyE_rhM3IQeFQCCeZJCNgadiftyUVNRwAPI-HnqgmDiTqbJ2Q2E5saGwX7Xsu4a/https%3A%2F%2Fwww.centralnic.com > > <https://secure-web.cisco.com/13-E0oRnwyeA8SenfNfBy4KMSGtCic3FVW1vcuJDPs9XkobKDsEK0YgbQpenao1bT_oCMeSL8v7X7dPPo_gFf_bXkz8tTZU92gvbXuBLb478kPPRkPRaJii-ywI_5V6zzMjROQ4O6fCkU2zeI5OntXAtYcD9BSWMQJAnDjXel6jy_Gli1quLEb9mnco30J8Uq_pyE_rhM3IQeFQCCeZJCNgadiftyUVNRwAPI-HnqgmDiTqbJ2Q2E5saGwX7Xsu4a/https%3A%2F%2Fwww.centralnic.com> > > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > > https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > <https://secure-web.cisco.com/1-yb-57do9pn1MCHOdXmj15RKh_-Ull0dVu2cfvvH15Gti90YKFeNhBhj2ykIWxZgJ2j8BaYf-4TxPq75aoXjTqf0sFN3AyFWIo74k376pubPrT1E7z_wvqtwK5RpZgX_Nsa2NAVmKRr9HxhSIEt778NFHI2wCbsBi8gVnDpMnAfXKXdVSh03KTvqYZVaR9wVxluNfJC2IFHM5voS8BdnPfJ6teILwZOZflHWT1TVKg9NYeF1bgIugt5iQtMahv4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> > > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext > <https://www.ietf.org/mailman/listinfo/regext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
