+1 > On 5 Jun 2024, at 09:58, Mario Loffredo > <mario.loffredo=40iit.cnr...@dmarc.ietf.org> wrote: > > Hi Jim, > Il 03/06/2024 20:05, James Galvin ha scritto: >> It is a great thing that we have such interest in preparing for extended >> technical discussions at this next REGEXT meeting. >> >> We have until Friday, 7 June, to make adjustments to the request. >> >> Would folks please send suggested agenda items to the list with a desire for >> how much time you’d like to spend talking about them? > Would also like to talk about the future of rdap-jscontact. > If there is no interest from the WG in moving the document forward, have no > problem to drop it any time but I would like the WG to take a clear position. > I speak on my behalf but I imagine that Gavin as co-author agrees on that. > That said, I make some considerations here below: > - yesterday, in his presentation [regiops.net] at ROW about WHOIS vs RDAP > inconsistencies, Simon Fernandez said that the jCard format is chaotic and > hardly parseable. This is another demontration that jCard is considered unfit > and we should replace it with another one more manageable. > - in light of Andy's feedback on RFC9537 and repeating what I had already > written in this thread [mailarchive.ietf.org], do believe that representing > collections in contact data through maps instead of arrays (or worse arrays > of arrays) would greatly simplify the JSONPath expressions used in redaction > as the name selector would be mostly used in place of index selectors and > filters > - the obligation/recommendation included in NIS2 about avoiding contact data > duplication makes me envisage that in the future we could have validated > contacts shared among the registries and those contacts will be likely > identified through universal identifiers. As a result of this, a contact data > format including a universal identifier could be useful. > > Hope it could be helpful to resume the discussion about using JSContact or > any other well-structured contact data format in RDAP. > > Best, > Mario > >> >> I know I have my own ideas but I do think it’s important to hear from the >> working group first. >> >> Antoin and I will make an adjustment to the requested time based on what >> folks want to move forward with. >> >> Thanks! >> >> Jim >> >> >> >> On 3 Jun 2024, at 10:40, IETF Meeting Session Request Tool wrote: >> >> >>> A new meeting session request has just been submitted by Antoin Verschuren, >>> a >>> Chair of the REGEXT Working Group. >>> >>> >>> --------------------------------------------------------- >>> Working Group Name: Registration Protocols Extensions >>> Area Name: Applications and Real-Time Area >>> Session Requester: Antoin Verschuren >>> >>> >>> Number of Sessions: 1 >>> Length of Session(s): 2 Hours >>> Number of Attendees: 50 >>> Conflicts to Avoid: >>> Chair conflict: dnsop dance saag sidrops savnet grow deleg >>> Key participant conflict: dispatch secdispatch >>> >>> >>> >>> >>> Participants who must be present: >>> >>> Resources Requested: >>> >>> Special Requests: >>> >>> --------------------------------------------------------- >>> >> _______________________________________________ >> regext mailing list -- regext@ietf.org >> To unsubscribe send an email to regext-le...@ietf.org >> > -- > Dott. Mario Loffredo > Senior Technologist > Technological Unit “Digital Innovation” > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > Address: Via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Web: http://www.iit.cnr.it/mario.loffredo [iit.cnr.it] > _______________________________________________ > regext mailing list -- regext@ietf.org > To unsubscribe send an email to regext-le...@ietf.org
-- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
