[regext] Re: Fwd: New Version Notification for draft-newton-regext-rdap-considerations-on-rfc9537-00.txt
istration Data Access Protocol (RDAP) Response”. The considerations in this document have arisen from problems raised by two separate teams attempting to implement RFC 9537 in both an RDAP web client and an RDAP command line client. Some of these problems may be insurmountable, leaving portions of RFC 9537 non-interoperable between clients and servers, while other problems place a high degree of complexity upon clients. The IETF Secretariat ___ regext mailing list --regext@ietf.org To unsubscribe send an email toregext-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 ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: regext - New Meeting Session Request for IETF 120
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 <https://regiops.net/sites/default/files/documents/8-ROW13-Simon%20Fernandez-WHOIS%20Right%3F%20An%20Analysis%20of%20WHOIS%20and%20RDAP%20Consistency.pdf> 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 <https://mailarchive.ietf.org/arch/msg/regext/I-CG4IwNauiU-6KiNwvaaPU5msQ/>, 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 toregext-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 ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Re: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt
is welcome! >> >> G. >> >>> Begin forwarded message: >>> >>> From: >>> Subject: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt >>> Date: 23 May 2024 at 20:42:19 BST >>> To: Andy Newton , Gavin Brown >>> >>> A new version of Internet-Draft draft-brown-rdap-referrals-00.txt has been >>> successfully submitted by Gavin Brown and posted to the >>> IETF repository. >>> >>> Name: draft-brown-rdap-referrals >>> Revision: 00 >>> Title: Efficient RDAP Referrals >>> Date: 2024-05-23 >>> Group: Individual Submission >>> Pages: 6 >>> URL: https://www.ietf.org/archive/id/draft-brown-rdap-referrals-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-brown-rdap-referrals/ >>> HTML: https://www.ietf.org/archive/id/draft-brown-rdap-referrals-00.html >>> HTMLized: https://datatracker.ietf.org/doc/html/draft-brown-rdap-referrals >>> >>> >>> Abstract: >>> >>> This document describes how RDAP servers can provide HTTP "Link" >>> header fields in RDAP responses to allow RDAP clients to efficiently >>> determine the URL of related RDAP records for a resource. >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> -- >>> 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 > > ___ > regext mailing list -- regext@ietf.org > To unsubscribe send an email to regext-le...@ietf.org ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org ___ regext mailing list --regext@ietf.org To unsubscribe send an email toregext-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 ___ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-18.txt
Hi, in this new version some feedback by Andy has been addressed, some sections have been slightly revised and I-Ds have been replaced with RFCs in references. Have also added to the jscontact-tools library a wrapper to demonstrate how easy is to handle the JSContact format in an EPP-like manner (see see at https://github.com/consiglionazionaledellericerche/jscontact-tools?tab=readme-ov-file#using-jscontact-in-rdap). Keeping aside for the moment the method used by clients to request for JSContact in RDAP responses, which depends on the outcomes of the discussion about how to handle RDAP extensions, think that next thing to address is how the tansition process should take place. The draft presents a solution that aims to minimize the response payload during the transition and enable servers to realize when their clients have deprecated the jCard format. In addition, the proposed solution is not finalized to forcefully deprecate the jCard format (obviously, that would be hopeful) as the JSContact format would be handled as any other optional extension. Of course, the authors would welcome any alternative leading to consensus. Any feedback is very appreciated. Best, Mario Messaggio Inoltrato Oggetto: New Version Notification for draft-ietf-regext-rdap-jscontact-18.txt Data: Thu, 16 May 2024 00:41:09 -0700 Mittente: internet-dra...@ietf.org A: Gavin Brown , Mario Loffredo A new version of Internet-Draft draft-ietf-regext-rdap-jscontact-18.txt has been successfully submitted by Mario Loffredo and posted to the IETF repository. Name: draft-ietf-regext-rdap-jscontact Revision: 18 Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses Date: 2024-05-16 Group: regext Pages: 26 URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-18.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-jscontact-18 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 To unsubscribe send an email to regext-le...@ietf.org
Re: [regext] WGLC: draft-ietf-regext-epp-ttl-08
+1 Mario Il 29/04/2024 16:27, James Galvin ha scritto: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/08/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 13 May 2024. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Andy Newton. Thanks, Antoin and Jim REGEXT WG Co-Chairs ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Re-chartering REGEXT?
e. • Data formats for files exchanged between registration entities that need insertion in or extraction from EPP or RDAP. • Technical guidance for registration processes that are supported by EPP or RDAP.” ___ regext mailing list regext@ietf.org <mailto:regext@ietf.org> https://secure-web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPMeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFakvQ61DRHxQLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9_PLgXgM8eklr87_hvlNWXU_-41hgJWbb4kMACk-BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2ZmhGFmjGtaGbOFxjlmkUq5FUncipetsTP1KpPA-g33rNu37yQBieczmC5kkY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPMeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFakvQ61DRHxQLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9_PLgXgM8eklr87_hvlNWXU_-41hgJWbb4kMACk-BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2ZmhGFmjGtaGbOFxjlmkUq5FUncipetsTP1KpPA-g33rNu37yQBieczmC5kkY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> ___ regext mailing list regext@ietf.org <mailto:regext@ietf.org> https://secure-web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPMeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFakvQ61DRHxQLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9_PLgXgM8eklr87_hvlNWXU_-41hgJWbb4kMACk-BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2ZmhGFmjGtaGbOFxjlmkUq5FUncipetsTP1KpPA-g33rNu37yQBieczmC5kkY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPMeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFakvQ61DRHxQLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9_PLgXgM8eklr87_hvlNWXU_-41hgJWbb4kMACk-BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2ZmhGFmjGtaGbOFxjlmkUq5FUncipetsTP1KpPA-g33rNu37yQBieczmC5kkY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP evolution and the REGEXT charter
Il 22/03/2024 13:01, Gould, James ha scritto: Andy, It's not a question of fairness, but a question of what is defined in EPP RFC 5730 as it comes to extensibility of EPP. EPP RFC 5730 includes extensibility of transport, as reflected in Section 2.1. This is what I meant to say with my previous post. Mapping EPP over a new transport is compliant with RFC5730 because it's a kind of extension defined and allowed by that document itself. Otherwise I do wonder what would be the purpose of Section 2.1. On the contrary, as expressed by many of us including me, REPP would be something different from EPP , hence it would require to recharter RegExt. Otherwise I wouldn't catch the purpose of the feedback provided by this WG about first EoH version to require it to be fully compliant with RFC5730. And that version was really almost compliant with RFC5730. Finally, I'd allso like to outline that some time ago I provided Maarten with a more comprehensive feedback about REPP on CENTR R list. It included the objections I have just raised here. Am sure that I've always been fair. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP evolution and the REGEXT charter
Hi Jasdip, IMO, REPP is not an "EPP extension" as defined by RFC5730. It provides neither just a switch of transport (like EoH and EoQ) nor an extension to EPP comands and responses. Instead, it presents a full revision of EPP that maps some EPP features onto HTTP features. Moreover, the current proposal is incompatible with some existing or future documents including extensions to EPP query commands (see Jody's question at last meeting about REPP compatibility with the Fee Extension). On the contrary, in the spirit of achieving a full compliance with RFC5730, .it is going to update its EPP implementation that has been working since 2009. With regard to a possible RegExt rechartering, I also don't think we need it. RFC5730 already allows for implementing EPP over multiple transports. But it does even more, it makes some examples of possible alternatives to TCP. Therefore, leaving aside for the moment the debate about considering a new transport as an extension or not, it would be paradoxical if the protocol itself admitted other transports than TCP but it wouldn't be allowed to standardize them just like it has been done for TCP :-( Best, Mario Il 22/03/2024 01:12, Jasdip Singh ha scritto: Hi. Curious if the newly proposed “RESTful EPP” is considered a new protocol that is different from EPP, or is it an “extension” of EPP? (AFAICT, the former seems outside the current regext charter.) Thanks, Jasdip *From: *regext on behalf of Hollenbeck, Scott *Date: *Friday, March 22, 2024 at 9:56 AM *To: *jgould=40verisign@dmarc.ietf.org , maarten.wullink=40sidn...@dmarc.ietf.org , regext@ietf.org *Subject: *Re: [regext] EPP evolution and the REGEXT charter *From:*regext *On Behalf Of *Gould, James *Sent:* Thursday, March 21, 2024 7:49 PM *To:* maarten.wullink=40sidn...@dmarc.ietf.org; regext@ietf.org *Subject:* [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter *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. Maarten, The charter refers to EPP extensions, which transports is a form of an EPP extension. RFC 5730 defines the extension points for EPP and includes support for extending the transports based on Section 2.1 “Transport Mapping Considerations”. I don’t believe that there is a need to revise the REGEXT charter to support the additional of new EPP transports. */[SAH] Agreed. New transport mappings are just another type of extension as long as they preserve the data model described in RFC 5730./* *//* */Scott/* ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Shepherd's wirteup about rir-search completed
Hi Chairs, this is to inform you that I just completed the shepherd's writeup of rir-search. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt
Il 22/02/2024 16:00, Hollenbeck, Scott ha scritto: Mario, allow me to make a minor adjustment to my suggestion: “Servers MUST implement at least one method of access control that limits server connection access to only authorized clients. Implementation of multiple access control methods is RECOMMENDED.” [ML] Agreed. Mario We need to be clear that unauthorized clients should NOT be allowed to send ANYTHING to a server that might get processed as part of an EPP interaction. Scott *From:* regext *On Behalf Of *Mario Loffredo *Sent:* Thursday, February 22, 2024 9:30 AM *To:* Hollenbeck, Scott ; regext@ietf.org *Subject:* [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.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 Scott, Il 22/02/2024 13:54, Hollenbeck, Scott ha scritto: I understand that there are options available for client authentication, and that this isn’t necessarily easy for clients. However, there are known attacks that can be perpetrated against servers that allow TCP or TLS connections from unauthorized clients. One example is described here: https://hackcompute.com/hacking-epp-servers/ <https://secure-web.cisco.com/1ue8wHGIlyxN-IrXsOyzbTYD2z-ImIVuVvGbKx2t8qM3_V_9oPO2stGT8UYOaw49CYpBUhOaoiyd39bmY4CzNUClJixr7ufI3bKnxp_ociah6fFteJluIGb4rWt7wzCHlOsXKuThrqfwmuQKmJ-uaH2YphL5uivdiSfE1M8WROt3QoulHSHuBbNLLeHnXrF6bODtiboQVTmt2jW4C7YnmY2uHo2B93UgH73WgICFH7tWclRkLp6H3jfdX1hRw7kLsxE3DTl-AIx2d_W83y9Gk-IhrvuLJxh3OlyX3mH0FZWk/https%3A%2F%2Fhackcompute.com%2Fhacking-epp-servers%2F> [ML] I will look into this. If there’s something about client certificates that makes them impossible to use, fine, replace them with another required mechanism. As such, the draft should say something like this: Servers MUST implement at least one method of access control that limits server access to only authorized clients. Implementation of multiple access control methods is RECOMMENDED. [ML] Sounds reasonable to me. I'll incorporate this change into the next version. Thanks a lot for your feedback. Best, Mario Scott *From:* Mario Loffredo <mailto:mario.loffredo=40iit.cnr...@dmarc.ietf.org> *Sent:* Thursday, February 22, 2024 1:52 AM *To:* Hollenbeck, Scott <mailto:shollenb...@verisign.com>; regext@ietf.org *Subject:* [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.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 Scott, thanks for your quick reply. Please find my comment below. Il 21/02/2024 13:47, Hollenbeck, Scott ha scritto: Tanks for posting the draft, Mario. One quick question: RFC 5734 (Extensible Provisioning Protocol (EPP) Transport over TCP) states that “Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED”. Section 8 of the draft weakens this requirement, stating that “servers SHOULD require clients to present a digital certificate”. HTTPS requires both TCP and TLS, so why weaken the requirement? [ML] There are technical (1-2), ethical (3) and practical (4) reasons. With regard to reasons 3-4, I can speak on behalf of .it but I'm pretty sure the situation is quite the same in other ccTLDs. 1) In TLS (RFC 5246), servers must provide clients with a certificate but clients may provide servers with a certificate if it is requested by servers. It all depends on the application protocol built on top of HTTPS. If the purpose of requiring clients to issue a certificate is implementing a kind of 2FA to enforce EPP client authentication in addition to client's credentials, that is not the only way to go. For example, .it requires that a client ip address could be used by one only registrar where a registrar can use multiple client ip addresses. The association between them is created out-of-band, stored in the underlying db and recorded in the HTTP session, once it is started . Therefore, at any request, the server (i.e. one of the backend server cited below) is able to verify that noone is trying to impersonate someone else. Definitvely, I wouldn't say that using SHOULD instead of MUST weakens the requirement of enforcing client authentication as long as alternative measures could be as secure as client certificates. 2) In an L7 load balancer (LB), clients issue the requests over HTTPS and the LB forwards the requests to the backend servers (BSs) over HTTP. This is to speed up the communication between the LB and the BSs. There
Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt
Hi Scott, Il 22/02/2024 13:54, Hollenbeck, Scott ha scritto: I understand that there are options available for client authentication, and that this isn’t necessarily easy for clients. However, there are known attacks that can be perpetrated against servers that allow TCP or TLS connections from unauthorized clients. One example is described here: https://hackcompute.com/hacking-epp-servers/ [ML] I will look into this. If there’s something about client certificates that makes them impossible to use, fine, replace them with another required mechanism. As such, the draft should say something like this: Servers MUST implement at least one method of access control that limits server access to only authorized clients. Implementation of multiple access control methods is RECOMMENDED. [ML] Sounds reasonable to me. I'll incorporate this change into the next version. Thanks a lot for your feedback. Best, Mario Scott *From:* Mario Loffredo *Sent:* Thursday, February 22, 2024 1:52 AM *To:* Hollenbeck, Scott ; regext@ietf.org *Subject:* [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.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 Scott, thanks for your quick reply. Please find my comment below. Il 21/02/2024 13:47, Hollenbeck, Scott ha scritto: Tanks for posting the draft, Mario. One quick question: RFC 5734 (Extensible Provisioning Protocol (EPP) Transport over TCP) states that “Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED”. Section 8 of the draft weakens this requirement, stating that “servers SHOULD require clients to present a digital certificate”. HTTPS requires both TCP and TLS, so why weaken the requirement? [ML] There are technical (1-2), ethical (3) and practical (4) reasons. With regard to reasons 3-4, I can speak on behalf of .it but I'm pretty sure the situation is quite the same in other ccTLDs. 1) In TLS (RFC 5246), servers must provide clients with a certificate but clients may provide servers with a certificate if it is requested by servers. It all depends on the application protocol built on top of HTTPS. If the purpose of requiring clients to issue a certificate is implementing a kind of 2FA to enforce EPP client authentication in addition to client's credentials, that is not the only way to go. For example, .it requires that a client ip address could be used by one only registrar where a registrar can use multiple client ip addresses. The association between them is created out-of-band, stored in the underlying db and recorded in the HTTP session, once it is started . Therefore, at any request, the server (i.e. one of the backend server cited below) is able to verify that noone is trying to impersonate someone else. Definitvely, I wouldn't say that using SHOULD instead of MUST weakens the requirement of enforcing client authentication as long as alternative measures could be as secure as client certificates. 2) In an L7 load balancer (LB), clients issue the requests over HTTPS and the LB forwards the requests to the backend servers (BSs) over HTTP. This is to speed up the communication between the LB and the BSs. There is no need to set up an SSL channel between them because the LB is normally exposed on the border of a protected network while the BSs are inside that network. A firewall filters the access by allowing only the communication on port 443 and only from a selected list of ip addresses. The LB logic for routing the incoming requests is very simple, hence you can easily forward a client ip address but it would be much harder to extract the client identity from a certificate (i.e. either CN or SAN) and forward it through an ad-hoc HTTP request header field to let the BS verifies the client identity. 3) Most of .it registrars (~ 1100) are italian SMEs managing only .it domains. When, in 2009, .it migrated from the old registration system, based on issuing fax, to the new one, based on issuing EPP commands over HTTP, the mission of that transition was to reduce as much as possible the technological effort required to registrars to comply with the new rules and avoid to discriminate small players who could not be as technologically powerful as the big ones. To make that transition as smooth as possible, we provided some measures to support them in everything. At that time, we evaluated client certificates could appear a practice increasing that technological divide. Then we opted for other fairer and as effective practices. 4) .it domain names market is very dynamic. Companies merge and, as a result of changing the company names, new registrars are registered with new credentials and new client certificate would be needed. Client IP addresses looks more stable
Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt
Hi Scott, thanks for your quick reply. Please find my comment below. Il 21/02/2024 13:47, Hollenbeck, Scott ha scritto: Tanks for posting the draft, Mario. One quick question: RFC 5734 (Extensible Provisioning Protocol (EPP) Transport over TCP) states that “Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED”. Section 8 of the draft weakens this requirement, stating that “servers SHOULD require clients to present a digital certificate”. HTTPS requires both TCP and TLS, so why weaken the requirement? [ML] There are technical (1-2), ethical (3) and practical (4) reasons. With regard to reasons 3-4, I can speak on behalf of .it but I'm pretty sure the situation is quite the same in other ccTLDs. 1) In TLS (RFC 5246), servers must provide clients with a certificate but clients may provide servers with a certificate if it is requested by servers. It all depends on the application protocol built on top of HTTPS. If the purpose of requiring clients to issue a certificate is implementing a kind of 2FA to enforce EPP client authentication in addition to client's credentials, that is not the only way to go. For example, .it requires that a client ip address could be used by one only registrar where a registrar can use multiple client ip addresses. The association between them is created out-of-band, stored in the underlying db and recorded in the HTTP session, once it is started . Therefore, at any request, the server (i.e. one of the backend server cited below) is able to verify that noone is trying to impersonate someone else. Definitvely, I wouldn't say that using SHOULD instead of MUST weakens the requirement of enforcing client authentication as long as alternative measures could be as secure as client certificates. 2) In an L7 load balancer (LB), clients issue the requests over HTTPS and the LB forwards the requests to the backend servers (BSs) over HTTP. This is to speed up the communication between the LB and the BSs. There is no need to set up an SSL channel between them because the LB is normally exposed on the border of a protected network while the BSs are inside that network. A firewall filters the access by allowing only the communication on port 443 and only from a selected list of ip addresses. The LB logic for routing the incoming requests is very simple, hence you can easily forward a client ip address but it would be much harder to extract the client identity from a certificate (i.e. either CN or SAN) and forward it through an ad-hoc HTTP request header field to let the BS verifies the client identity. 3) Most of .it registrars (~ 1100) are italian SMEs managing only .it domains. When, in 2009, .it migrated from the old registration system, based on issuing fax, to the new one, based on issuing EPP commands over HTTP, the mission of that transition was to reduce as much as possible the technological effort required to registrars to comply with the new rules and avoid to discriminate small players who could not be as technologically powerful as the big ones. To make that transition as smooth as possible, we provided some measures to support them in everything. At that time, we evaluated client certificates could appear a practice increasing that technological divide. Then we opted for other fairer and as effective practices. 4) .it domain names market is very dynamic. Companies merge and, as a result of changing the company names, new registrars are registered with new credentials and new client certificate would be needed. Client IP addresses looks more stable. For sure, updating the set of allowed IP addresses per registrar doesn't cost a thing. I'm aware that talking about ethical reasons in a technical forum like RegExt might seem inappropriate but nonetheless think that often non-technical aspects have somewhat an influence on making technical decisions. My apologizes for the long post. Did my best to answer synthetically. Best, Mario Scott *From:* regext *On Behalf Of *Mario Loffredo *Sent:* Wednesday, February 21, 2024 2:15 AM *To:* regext@ietf.org *Subject:* [EXTERNAL] [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.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, just submitted a new version of draft-loffredo-regext-epp-over-http. Here in the following the most relevant updates: 1. Has been made fully compliant with RFC 5730 2. Aligns with the structure and makeup of EPP over TCP (EoT) in RFC 5734 3. Fully pluggable transport for EPP with EoT 4. Verisign added as co-authors If the agenda of next meeting was not full, I would like to have a 10-minute slot to present the updates a bit more in detail. Any feedback is appreciated. Best, Mario Messaggio Inoltrato *Oggetto
[regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt
Hi all, just submitted a new version of draft-loffredo-regext-epp-over-http. Here in the following the most relevant updates: 1. Has been made fully compliant with RFC 5730 2. Aligns with the structure and makeup of EPP over TCP (EoT) in RFC 5734 3. Fully pluggable transport for EPP with EoT 4. Verisign added as co-authors If the agenda of next meeting was not full, I would like to have a 10-minute slot to present the updates a bit more in detail. Any feedback is appreciated. Best, Mario Messaggio Inoltrato Oggetto: New Version Notification for draft-loffredo-regext-epp-over-http-03.txt Data: Tue, 20 Feb 2024 23:11:09 -0800 Mittente: internet-dra...@ietf.org A: Dan Keathley , Daniel Keathley , James Gould , Lorenzo Luconi Trombacchi , Lorenzo Trombacchi , Mario Loffredo , Maurizio Martinelli A new version of Internet-Draft draft-loffredo-regext-epp-over-http-03.txt has been successfully submitted by James Gould and posted to the IETF repository. Name: draft-loffredo-regext-epp-over-http Revision: 03 Title: Extensible Provisioning Protocol (EPP) Transport over HTTP Date: 2024-02-20 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-03.txt Status: https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/ HTMLized: https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http Diff: https://author-tools.ietf.org/iddiff?url2=draft-loffredo-regext-epp-over-http-03 Abstract: This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a Hypertext Transfer Protocol (HTTP) connection. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
Hi Antoin, please find my comments below. Il 19/02/2024 16:41, Antoin Verschuren ha scritto: So, if I understand this correctly, the chairs asked the document shepherd to declare that there were no substantial changes made during WGLC between versions 05 and 07 and all raised issues were addressed. The answer below I interpret as: We would like the permission from the WG to not only substantially change draft-ietf-regext-rdap-rir-search in a next version that we want to send to the IESG, but on top of that also clarify or even change the interpretation of RFC 9083. If this is the question, then we need to have a discussion what this will mean to other documents and it’s interpretation of RFC 9083 first, and perhaps even write this clarification down in a separate document if that is needed. When that is done and consensus is reached, we must issue a new WGLC for the next version of draft-ietf-regext-rdap-rir-search if that will contain these substantial changes suggested by the WG. [ML] Yes, that is the question. I would also like to outline that, in this case, the difference between correcting nits (i.e. , some unnecessary extension identifiers included in the rdapConformance array as it is shown in some examples) and changing substantially the draft depends just on the interpretation of RFC9083 and such a question revealed to be matter for WG discussion when the different interpretations came up. Best, Mario In order to reach consensus, all comments and support during a complete WGLC must be for a stable document. Otherwise we don’t know if people agree with what version of the document and which interpretation of RFC 9083. Regards, Antoin Op 19 feb. 2024, om 13:07 heeft Mario Loffredo het volgende geschreven: Hi Antoin, after a private discussion between James, Tom, Jasdip and me, we agreed on the following: 1) Some minor edits that don't substantially change the draft but clarify the meaning of some sentences will be done in next version 2) We would like the WG members express their own opinions on the substantial matter below. */RFC 9083 states the following for rdapConformance included in non-“help” RDAP responses:/* */·The data structure named "rdapConformance" is an array of strings, each providing a hint as to the specifications used in the construction of the response./* */·A response to any other request will include only identifiers for the specifications used in the construction of the response./* */There is no normative language that specifies exactly what identifiers are included in the response, where there is the language of “hints” and “used in construction of the response”. Below are options for what identifiers are included in the “rdapConformance” array that could be captured in the RDAP Extensions draft:/* /*Option 1) only the extension identifiers used to build the response with regard to the fields*/ /*Option 2) all of the extension identifiers that impact the build of the response, hence with regard to fields, values, and query members / query parameters used for the response (i.e. Option 1 + extension query identifiers and extension identifiers impacting response values)*/ /*Option 3) all of the extension identifiers defined by specs used to build the response (i.e. Option 2 + any extension identifier defined by referenced specs) */ *//* Option 1 corresponds to a literal interpretation of normative language in RFC 9083, while Option 2 extends its meaning. Option 3 is further extensive and corresponds to the interpretation used in rir-search. To better explain their position, the authors asked me to add the following note (please Tom and Jasdip elaborate, if you think I missed something or didn't present correctly your point of view): "documents may mandate specific behaviour around identifiers for the purposes of signalling, and it's fine for this sort of thing to override the requirement above. (nro_rdap_profile_asn_flat_0 and nro_rdap_profile_asn_hierarchical_0 are examples of this, where the document itself requires implementations to pick one or the other, and that's fine.)" Best, Mario Il 05/02/2024 15:35, Antoin Verschuren ha scritto: Hi All, After some prolonged discussion, the chairs will now close this working group last call that should have ended 11 December 2023. We have had comments and approval during WGLC from 4 working group participants and the document shepherd and no objections. That has lead to 2 new versions of the document during WGLC that started with version 05. The document shepherd for this document is Mario Loffredo. In order for the document to progress and sent to the IESG, the document shepherd will need to do a final review of the following: 1. Please confirm all suggested changes have been addressed in version 07. 2. Please ask James Gould to confirm his changes have been addressed as he promised to do another
Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
Hi Antoin, after a private discussion between James, Tom, Jasdip and me, we agreed on the following: 1) Some minor edits that don't substantially change the draft but clarify the meaning of some sentences will be done in next version 2) We would like the WG members express their own opinions on the substantial matter below. */RFC 9083 states the following for rdapConformance included in non-“help” RDAP responses:/* */·The data structure named "rdapConformance" is an array of strings, each providing a hint as to the specifications used in the construction of the response./* */·A response to any other request will include only identifiers for the specifications used in the construction of the response./* */There is no normative language that specifies exactly what identifiers are included in the response, where there is the language of “hints” and “used in construction of the response”. Below are options for what identifiers are included in the “rdapConformance” array that could be captured in the RDAP Extensions draft:/* /*Option 1) only the extension identifiers used to build the response with regard to the fields*/ /*Option 2) all of the extension identifiers that impact the build of the response, hence with regard to fields, values, and query members / query parameters used for the response (i.e. Option 1 + extension query identifiers and extension identifiers impacting response values)*/ /*Option 3) all of the extension identifiers defined by specs used to build the response (i.e. Option 2 + any extension identifier defined by referenced specs) */ *//* Option 1 corresponds to a literal interpretation of normative language in RFC 9083, while Option 2 extends its meaning. Option 3 is further extensive and corresponds to the interpretation used in rir-search. To better explain their position, the authors asked me to add the following note (please Tom and Jasdip elaborate, if you think I missed something or didn't present correctly your point of view): "documents may mandate specific behaviour around identifiers for the purposes of signalling, and it's fine for this sort of thing to override the requirement above. (nro_rdap_profile_asn_flat_0 and nro_rdap_profile_asn_hierarchical_0 are examples of this, where the document itself requires implementations to pick one or the other, and that's fine.)" Best, Mario Il 05/02/2024 15:35, Antoin Verschuren ha scritto: Hi All, After some prolonged discussion, the chairs will now close this working group last call that should have ended 11 December 2023. We have had comments and approval during WGLC from 4 working group participants and the document shepherd and no objections. That has lead to 2 new versions of the document during WGLC that started with version 05. The document shepherd for this document is Mario Loffredo. In order for the document to progress and sent to the IESG, the document shepherd will need to do a final review of the following: 1. Please confirm all suggested changes have been addressed in version 07. 2. Please ask James Gould to confirm his changes have been addressed as he promised to do another review. 3. Make sure the Nits are addressed. 4. Confirm that all changes between version 05 and version 07 are editorial and not substantive. 5. When all the above concerns are addressed, please write the document shepherd writeup. Thanks to everyone that contributed to this review! Regards, Jim and Antoin REGEXT WG Co-Chairs Op 27 nov. 2023, om 15:51 heeft Antoin Verschuren het volgende geschreven: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: RDAP RIR Search https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 11 December 2023. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Mario Loffredo. Thanks, Jim and Antoin REGEXT WG Co-Chairs ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list r
[regext] jscontact-tools
To everyone who is interested, have released a version of jscontact-tools including features that support RDAP implementers in dealing with JSContact without being friendly with the spec. Indeed, implementers can build a JSContact card for RDAP (as defined by rdap-jscontact document) and get the contact information as if they basically dealt with an EPP contact plus url and structured name (https://github.com/consiglionazionaledellericerche/jscontact-tools?tab=readme-ov-file#using-jscontact-in-rdap). At the same time, the source code shows how it has been very easy to implement those features. Any feedback is appreciated. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-gould-regext-rdap-versioning draft-newton-regext-rdap-extensions draft-newton-regext-rdap-x-media-type
+1 Mario Il 05/02/2024 15:37, James Galvin ha scritto: This is the formal adoption request for the following package of Internet Drafts: Versioning in the Registration Data Access Protocol (RDAP) https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ RDAP Extensions https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/ An RDAP With Extensions Media Type https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/ Please review these drafts to see if you think they are suitable for adoption by REGEXT and comment to this message on the list, clearly stating your view. This Call For Adoption will close on Monday, 19 February. If there are no objections, the chairs will consider these documents adopted. Thanks, Your REGEXT co-chairs Antoin and Jim ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: WG LAST CALL draft-ietf-regext-rdap-rir-search
Hi James, can you please confirm that all of your feedback on version -05 has been addressed in version -07 ? Best, Mario Messaggio Inoltrato Oggetto:Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search Data: Mon, 5 Feb 2024 15:35:28 +0100 Mittente: Antoin Verschuren A: regext Hi All, After some prolonged discussion, the chairs will now close this working group last call that should have ended 11 December 2023. We have had comments and approval during WGLC from 4 working group participants and the document shepherd and no objections. That has lead to 2 new versions of the document during WGLC that started with version 05. The document shepherd for this document is Mario Loffredo. In order for the document to progress and sent to the IESG, the document shepherd will need to do a final review of the following: 1. Please confirm all suggested changes have been addressed in version 07. 2. Please ask James Gould to confirm his changes have been addressed as he promised to do another review. 3. Make sure the Nits are addressed. 4. Confirm that all changes between version 05 and version 07 are editorial and not substantive. 5. When all the above concerns are addressed, please write the document shepherd writeup. Thanks to everyone that contributed to this review! Regards, Jim and Antoin REGEXT WG Co-Chairs Op 27 nov. 2023, om 15:51 heeft Antoin Verschuren het volgende geschreven: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: RDAP RIR Search https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 11 December 2023. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Mario Loffredo. Thanks, Jim and Antoin REGEXT WG Co-Chairs ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-hollenbeck-regext-epp-delete-bcp
I support adoption. Mario Il 29/01/2024 16:17, Antoin Verschuren ha scritto: This is the formal adoption request for Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP): https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/ Please review this draft to see if you think it is suitable for adoption by REGEXT and comment to this message on the list, clearly stating your view. Andy Newton already volunteered to be a document shepherd this item will be adopted. This Call For Adoption will close on Monday 12 February. If there are no objections, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
Hi Tom, please find my comment below. Il 26/01/2024 04:29, Tom Harrison ha scritto: Hi Mario, Thanks for your feedback. On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote: +1 Have just two further notes: 1) Think it would be good to add normative language about partial matching referencing Section 4.1 of RFC 9082 . Thanks, this has been added. 2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance array in the examples Section 4 should include only the extensions used in the response. For sure the response including the ipSearchResults array will never include the autnumSearchResults array and viceversa ;-) The same goes for the responses including the links about ips or autnums. Instead, the help response should include all the extensions implemented. As a result of this, the first two paragraphs of Section 6 should be modified as well. We think that the existing text/behaviour should be left as-is in this respect. Section 4.1 of 9083 says: A response to a "help" request will include identifiers for all of the specifications supported by the server. A response to any other request will include only identifiers for the specifications used in the construction of the response. and that any response which makes use of any part of the RIR search specification should therefore include all of the identifiers defined by the RIR search specification, since each of those identifiers will be "for [one of] the specifications used in the construction of the response". An alternative reading along the lines of your suggestion would require associating identifiers with specific functionality in the document. While that's relatively straightforward in this case, it would require extra, possibly unintuitive guidance in the document as to when identifiers should be included. It's also not clear that it yields much benefit for the client, either: while it would be possible in theory for a client to implement/understand only part of an extension, such that a response with a subset of the available identifiers could be processed without having to go to the trouble of implementing/understanding the whole extension, that doesn't seem like something that would come up much in practice, given that most extensions are quite short/straightforward. What do you think? Think it would be good to involve the WG in the diiscussion. Literally RFC 9083 states that only the identifiers of those extensions used in building a response can be included in the rdapConformance array. Have always thought that its purpose was to inform clients about the extension prefixes they should be ready to recognize when deserializing the response. For this reason, including in the rdapConformance array an extension identifier that is not used in the response could be misleading for clients. Besides, mentioning in rdapConformance only the extensions used in the response doesn't mean that either the server or the client can have a partial knowledge of the specification defining them. Otherwise wouldn't understand the need to distinguish between the rdapConformance value in the help response and that in the other responses. But my interpretation might be too restrictive as well as yours might be too permissive. Better to listen to other opinions and finally agree on a shared interpretation. Best, Mario -Tom ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-17.txt
Hi Andy, thanks for your reply. Again my comments inline. Il 11/12/2023 22:41, Andrew Newton ha scritto: On Fri, Dec 8, 2023 at 3:57 AM Mario Loffredo wrote: [ML] I would prefer "only express the items which are more likely used in RDAP". After all, SimpleContact is not an RFC and, as such, could be subject to changes resulting from the WG discussion. In this respect, have still retained the use of JSContact name components to represent structured names. Apart from it and the language property, this version doesn't include extra information. I am good with this compromise, however my memory of the IETF 117 session was that items such as structured names were not desired. [ML2] Think that, similarly to what is required by gTLD RDAP Response Profile (Section 1.1), we should mandate some properties and let servers be free to output additional JSContact properties. - clarify the use of 5733's "sp" (examples suggest it is a region code, but it is a string) [ML] Don't think that we need to further clarify this. Appendix A already clarifies that the region JSContact address component corresponds to the region VCard ADR component. Hence, the region JSContact address component is a string. I should have been clearer in my request. I don't think normative text is needed, but rather some informative text to remind the reader of this as the 5733 example shows what can easily be mistaken as a region code. [ML2] There is nothing stating that the region address component must be a code. It could be a code or not depending on how servers have set the region component of the jCard adr element thus far. Besides, examples are not normative. Hence, can't see how a reader can derive that. Anyway, if it could be helpful, I can change the example. - define RFC 8605 CONTACT-URI is a JSContact link of type "contact" [ML] Done. - more specificity of the 5733 int/loc mapping (use of und-Latn and some clarity around the keys). [ML] Can you please elaborate this by providing some examples ? The idea is to specify 5733 "int" data as und-Latn. Yes, I'll work up some examples and provide them to you. [ML2] OK - restrict localizations from using patch objects (it looks like this is the case in the latest drafts). [ML] Sorry if I miss the meaning of this. What should be the alternative mechanism to represent localizations without using the "localizations" property. My apologies. I meant to convey that I believe this is no longer an issue. In line with the use of int/loc in RFC5733, we could use the same types for both localizations and localized objects (e.g. we can add two addresses to the "addresses" map) but we'd loose the information about the localization language. I agree. Let's not do that. Hopefully the examples I provide will be better. - clarity on hybrid address types (found in 5733 but also in other registry models) [ML] Can you please clarify which kind of hybrid address types you meant ? Hybrid types are where parts of the address are structured and other parts are not. For example, locality and country may be structured but the rest of the address is not. [M2] Sorry but I don't catch this. If you talk about address parts, it means that you have already structured the address. An unstructured address is a text where you can't distinguish the single parts. With respect to the address defined by RFC5733, the only part that is further structured is the street information. Likewise, you can have multiple "name" address components in JSContact. - make signaling survive redirects [ML] It seems to me that the WG hasn't yet taken a final position on this, discussion is still ongoing. So, at least for this version, I retained the jscard query parameter. I am not willing to compromise on this especially as there is a workable solution. Any IETF authored RDAP extension MUST be compatible with the current RDAP ecosystem in its intended usage. [ML2] Think that signaling the request for the JSContact format is a minor issue. Would cost nothing to switch to the use of the Accept header but until we'll reach consensus on this topic, other solutions are potentially acceptable including using a dedicated parameter or the versioning parameter. Best, Mario -andy -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact
Hi Andy, please find my comments inline. Il 07/12/2023 21:05, Andrew Newton ha scritto: On Tue, Nov 28, 2023 at 5:39 AM Mario Loffredo wrote: [ML] Since it talks about "content negotiation", rdap-x regards clients signaling their preferences about response extensions or, at most, extensions involving both the response and the request. With regard to pure request extensions, clients should signal preferences by using query parameters prefixed by opaque extension identifiers as defined in rdap-extensions. This in turn implies that, on one hand, rdap-x is strictly bound to rdap-extensions and, on the other hand, instead of what is stated in Section 6 of rdap-extensions, even the extensions created by IETF MUST use the extension identifier as a prefix. Do you agree ? The important part is that extensions have identifiers. The use of the identifiers as prefixes for JSON names or URL paths or query parameters is a separate issue. [ML] We should figure out a solution that fits any extension regardless of the fact that it involves only the response (which is the most likely use case), the request or both. In this respect, it seems to me that the meaning of both Accept and Content-Type headers would be extended in the RDAP context. [ML] It could be an issue if we decide to start using content negotiation. The media type has not influenced the RDAP response so far. With all due respect, that is incorrect. Current RDAP does do content negotiation. Section 4.2 of RFC 7480 says the accept header can have either application/rdap+json, application/json, or both and the content-type header must have application/rdap+json. [ML] It doesn't seem to me a real content negotiation since, per what is stated in Section 4.2 of RFC7480, whatever it is the media type the client specifies in the Accept header, the server always provides the same Content-Type value and, most of all, the same response content. To indicate to servers that an RDAP response is desired, clients include an Accept header field with an RDAP-specific JSON media type, the generic JSON media type, or both. Servers receiving an RDAP request return an entity with a Content-Type header containing the RDAP-specific JSON media type. This is the first case we come across where the Content-Type value and the content should be different based on the value of the Accept header. If the Accept header value was changed by the cache, client preferences would basically be ignored and the response wouldn't be the one expected by the client. For this reason, in my opinion, it would be better to further investigate. Best, Mario -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] ACTION REQUESTED: Re: RDAP-X draft adoption
Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-jscontact%2F> https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/ <https://secure-web.cisco.com/1a-3X4qV0mHjwRXynJmerEbK47F9vDkdT29ilFGzopWUKvznE8BJCmDCundvB0K3XiPXLNyEVpV7Z5y0V6B3bRGjBPPjslP3nqO9VEQiQ8cUBBN_82O9gkc7plmWEFnliCpmUkW7n_sgBg9DJgKuoloTXchUt2woEY4BTGzYZdJsgJLu7RB3r8I8JuXKVYAI6NkU_6ROMTm8I42OI3hG-D5yEtvATfpxVwnsXF_DtfcdtNgbbUKqSTu0IZIR4dclFNZvWW7zroiywf7uBbwrerWD_XOk-5Qh_Riw6iOSiNcM/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-simple-contact%2F> The Chairs suggest that the simple-contact document should also be adopted, to move forward on the Experimental track with jsContact, and that we consider if either is impacted by the solution(s) to be proposed. Thanks, Antoin and Jim On 14 Nov 2023, at 18:26, Jasdip Singh wrote: Hello Antoin, Jim, Given the ongoing discussion on how to negotiate extensions between RDAP clients and servers (using HTTP headers versus query parameters), be it for SimpleContact [1], JSContact [2], or versioning in RDAP [3], Andy and I want to request a call for WG adoption of the RDAP-X draft [4]. We believe that the HTTP headers-based approach could help unify extensions negotiation across the RDAP ecosystem. Thanks, Jasdip & Andy [1] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/ <https://secure-web.cisco.com/1a-3X4qV0mHjwRXynJmerEbK47F9vDkdT29ilFGzopWUKvznE8BJCmDCundvB0K3XiPXLNyEVpV7Z5y0V6B3bRGjBPPjslP3nqO9VEQiQ8cUBBN_82O9gkc7plmWEFnliCpmUkW7n_sgBg9DJgKuoloTXchUt2woEY4BTGzYZdJsgJLu7RB3r8I8JuXKVYAI6NkU_6ROMTm8I42OI3hG-D5yEtvATfpxVwnsXF_DtfcdtNgbbUKqSTu0IZIR4dclFNZvWW7zroiywf7uBbwrerWD_XOk-5Qh_Riw6iOSiNcM/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-simple-contact%2F> [2] https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ <https://secure-web.cisco.com/1S9ALApi40ba4zWCpUTXYYjMunNt48SIfnUV-8edz0DsRDFt5n8btojt93HE1usEXJoGyQ6iqqOT-SWBwrX_YlnEuHWsBafhxAUpe3Aq3hAtzhnRPpeij3d8xSGmg64SMsHvXNxnixfYy83zq1lbUMhFKOvkWFYB2ZuAs6vL1x5rplznSm005msv_VHqboptdHU3PscEqbXrvGQcB-vmlz14aHPlzS9VtelNaKtE4LyHJZvZxd-eLJ_ZY-hihFCPF04L-9oBdVu_BaX9HXjncTs_ZfaWrskVeEnR01X0gmbo/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-jscontact%2F> [3] https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ <https://secure-web.cisco.com/1QCHC-8xG9hJOoNbDI71pTXPcfNXNxXahQ0yAk0Kh8n3TXFaZLQfStyi73ETpLrp_VAHHTyrIcEJ1weZ5qZK0_cMTDTToIZEXQTyVvz1nTTW2OeinyEGs8qLf6H8JMh4D95TGSm8YxgqIGgdjwc44vpZ1HlC681iv-gRwvPf44zqTfXU7Ea2Y0kdFm3MdTltH9A-lyRa62J8JCOpzibzxwuOlV9nyEZRbgGx-igLxtkEXJx9YuGuT4b4hIrWyi9BEyLDDhYIUsv1VHWfnOXcZ98-fW-vSrVZhf4yJVDKmywc/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gould-regext-rdap-versioning%2F> [4] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/ <https://secure-web.cisco.com/1vynEGONnD6c3jpzASNi5JktCxoaatpSGQAe_7sPbWti_DS6KBeAEzmjYodzPnMkGJFZSes0qKsvlXGLTvk-UM4ES8robG3bVG0wp-U5YLKrqMw3XHYqIhzRzlozE3u9f2BfrayUT6rMVulRSqQAaCpGb082NbSazOzqabjjrN0TMq5GEyFK712UYoAAj1z3Xkr2dm9i0MKG8qfQduKAv5EBZ5mR6GZBz8gbqkp_OQ70hqPpAGjQO1L05zXkNRAksLsw4fQINAQ3vk1cINy1G1snWMle58uKD22RAzuGnyLo/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-x-media-type%2F> ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-17.txt
Hi all, this new version partially addresses the feedback from Andy. Please Andy and Tom find below a detailed reply to what you think that JSContact profile for RDAP should include:. - only express the items in SimpleContact [ML] I would prefer "only express the items which are more likely used in RDAP". After all, SimpleContact is not an RFC and, as such, could be subject to changes resulting from the WG discussion. In this respect, have still retained the use of JSContact name components to represent structured names. Apart from it and the language property, this version doesn't include extra information. - clarify the use of 5733's "sp" (examples suggest it is a region code, but it is a string) [ML] Don't think that we need to further clarify this. Appendix A already clarifies that the region JSContact address component corresponds to the region VCard ADR component. Hence, the region JSContact address component is a string. - define RFC 8605 CONTACT-URI is a JSContact link of type "contact" [ML] Done. - more specificity of the 5733 int/loc mapping (use of und-Latn and some clarity around the keys). [ML] Can you please elaborate this by providing some examples ? - restrict localizations from using patch objects (it looks like this is the case in the latest drafts). [ML] Sorry if I miss the meaning of this. What should be the alternative mechanism to represent localizations without using the "localizations" property. In line with the use of int/loc in RFC5733, we could use the same types for both localizations and localized objects (e.g. we can add two addresses to the "addresses" map) but we'd loose the information about the localization language. - restricting to JSContact 1.0. [ML] Done - clarity around JSContact links vs RDAP links [ML] Have specified what JSContact links are for. - define a more concrete scheme on sequenced IDs (and some examples) [ML] Have further specified the any unregistered map key should follow a pre-defined scheme. - clarity on hybrid address types (found in 5733 but also in other registry models) [ML] Can you please clarify which kind of hybrid address types you meant ? - make signaling survive redirects [ML] It seems to me that the WG hasn't yet taken a final position on this, discussion is still ongoing. So, at least for this version, I retained the jscard query parameter. Best, Mario Messaggio Inoltrato Oggetto: New Version Notification for draft-ietf-regext-rdap-jscontact-17.txt Data: Thu, 07 Dec 2023 23:54:07 -0800 Mittente: internet-dra...@ietf.org A: Gavin Brown , Mario Loffredo A new version of Internet-Draft draft-ietf-regext-rdap-jscontact-17.txt has been successfully submitted by Mario Loffredo and posted to the IETF repository. Name: draft-ietf-regext-rdap-jscontact Revision: 17 Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses Date: 2023-12-07 Group: regext Pages: 26 URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-17.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-jscontact-17 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 https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
+1 Have just two further notes: 1) Think it would be good to add normative language about partial matching referencing Section 4.1 of RFC 9082 . 2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance array in the examples Section 4 should include only the extensions used in the response. For sure the response including the ipSearchResults array will never include the autnumSearchResults array and viceversa ;-) The same goes for the responses including the links about ips or autnums. Instead, the help response should include all the extensions implemented. As a result of this, the first two paragraphs of Section 6 should be modified as well. Best, Mario Il 27/11/2023 15:51, Antoin Verschuren ha scritto: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: RDAP RIR Search https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/05/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 11 December 2023. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Mario Loffredo. Thanks, Jim and Antoin REGEXT WG Co-Chairs ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] JSContact - SimpleContact discussion follow up
Hi Andy, please find my comments inline. Il 27/11/2023 21:26, Andrew Newton ha scritto: Mario, Many thanks for this message. On Fri, Nov 17, 2023 at 5:57 AM Mario Loffredo wrote: 2) Chapter "Make it simpler" Prefer "Make it better". I mean, simplicity cannot be the only parameter used within IETF to evaluate a technical solution. IMO there are other parameters that are more important: flexibility, estensibility, efficiency. In addition, no one in their right mind deliberately makes a proposal inherently complex. JSContact started as simple as possible and get more complex to meet the requirements. As I recall, this is also what happened with jCard. What it ended up being was nothing like how it started. My original message on the concept of SimpleContact was born out of shock at just how complex JSContact had become. In that message, I proposed multiple paths, one of which was scoping down JSContact usage in RDAP to its simple parts. However, the thread turned into SimpleContact vs JSContact, arrays vs objects, us vs them, etc.. etc... etc... and that's how we got here. [ML] When rdap-jscontact was adopted, JSContact spec already included the extra information. From that perspective, JSContact was already more complex than a contact representation converted from RFC5733 information. But I do believe this was not considered relevant as the focus was on the information used in RDAP. Would also like to outline that some information might appear useless at present but could turn out useful in the future. Let's take for example the possible link between the uid property and the unique and persistent identifier as defined by the European eIDAS regulation <https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015R1501=EN> for the purposes of cross-border identification and validation of domain registrants as explained in a CENTR white paper <https://www.google.com/url?sa=t=j==s=web==2ahUKEwj0y9HD7eaCAxVqSvEDHdxOAh4QFnoECBIQAQ=https%3A%2F%2Fwww.centr.org%2Flibrary%2Flibrary%2Fdownload%2F10478%2F7435%2F41.html=AOvVaw1URRwBVrzbGecv4oa5nTCM=89978449>. I'm aware that a digital identifier will probably be publicly unavailable but it could be useful to some kind of authorized and legitimized users such as authorities and cybercrime investigators. With regard to the JSContact properties used in RDAP, never opposed prejudicially objects to arrays and arrays to maps. JSContact makes use of all of them depending on the implementation the authors have considered mostly efficient. But it is not too late to explore that path. If you are willing, I'd be happy to work with you on "SimpleContact expressed in JSContact". The basic premise would be to define a default RDAP extension profile of JSContact. Others may define their own extension profiles if they need more from JSContact, but the default profile would limit JSContact to expressing only that which is in SimpleContact. [ML] This is exactly the purpose of Section 3 of rdap-jscontact but have never got a relevant feedback about it. Meantime, just for a better clarity, have changed the document by removing from the example in rdap-jscontact the information that is unlikely used in RDAP. In more detail, We (because I talked to Tom about this) think the default profile would do the following: - only express the items in SimpleContact - clarify the use of 5733's "sp" (examples suggest it is a region code, but it is a string) - define RFC 8605 CONTACT-URI is a JSContact link of type "contact" - more specificity of the 5733 int/loc mapping (use of und-Latn and some clarity around the keys). - restrict localizations from using patch objects (it looks like this is the case in the latest drafts). - restricting to JSContact 1.0. - clarity around JSContact links vs RDAP links - define a more concrete scheme on sequenced IDs (and some examples) - clarity on hybrid address types (found in 5733 but also in other registry models) - make signaling survive redirects [ML] Thanks for this. Really appreciated. Think I will be able to address most of the points above in the next version. Some others need to be discussed. I'll provide feedback about it in a separate post. Again, others would be able to provide profiles that do more such as offering cryptocurrency wallets and avatars, etc [ML] Neither I think they will ever be used in RDAP but some other information might be instead. Taking a look at the eIDAS SAML Attribute Profile <https://www.google.com/url?sa=t=j==s=web==2ahUKEwjThv_N7uiCAxXdgf0HHdOGDcUQFnoECBMQAQ=https%3A%2F%2Fec.europa.eu%2Fdigital-building-blocks%2Fwikis%2Fdownload%2Fattachments%2F467109280%2Feidas_saml_attribute_profile_v1.0_2.pdf%3Fversion%3D1%26modificationDate%3D1639417533738%26api%3Dv2=AOvVaw1uVFGFgzXzfkFgyWapXQiF=89978449>, we can see that the mandatory properties for individuals include family and first
Re: [regext] Fwd: ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact
Hi Andy, again my comments inline. Il 27/11/2023 22:58, Andrew Newton ha scritto: My comments are inline: On Fri, Nov 17, 2023 at 7:18 AM Mario Loffredo wrote: [ML] Per what is stated in RFC 9083 Section 4.1, a pure request extension doesn't have to be included in the rdapConformance array of the related response when it is used in a query because the rdapConformance array is used to signal to the client only the extensions used in building the response. Per what is stated in Section3 of rdap-x draft, clients SHOULD give preference to the rdapConformance array in order to determine which extensions (including those requested ) were used to build the response. Let's suppose to use farv1_dnt in a query within an authenticated session. Have some questions: Should farv1 be included in the extensions parameter ? Good question. My inclination is to say that farv1 is about authentication and not content negotiation and therefore does not need to be in the extensions parameter. [ML] Since it talks about "content negotiation", rdap-x regards clients signaling their preferences about response extensions or, at most, extensions involving both the response and the request. With regard to pure request extensions, clients should signal preferences by using query parameters prefixed by opaque extension identifiers as defined in rdap-extensions. This in turn implies that, on one hand, rdap-x is strictly bound to rdap-extensions and, on the other hand, instead of what is stated in Section 6 of rdap-extensions, even the extensions created by IETF MUST use the extension identifier as a prefix. Do you agree ? What should be the server response when it's not included in the extensions parameter but is used in the query string ? It should continue processing the query parameters. Supposing that farv1 has to be included in the extensions parameter when farv1_dnt is used, how should a client interpret that farv1 is missing in rdapConformance ? I'm confused. Isn't this what the SHOULD above is about. Or are you suggesting that SHOULD is to be a MUST? [ML] No. Was simply trying to understand if the purpose of rdap-x was to signal client preferences about which extensions, regardless of their type, should be used by the server for processing the request. In the case of pure request extensions, the use of rdapConformance value looked a bit misleading to me. But you just clarified that the purpose of rdap-x is limited to signal only the response extensions. - AFAIK caches generally ignore Accept by default, so when content negotiation is first introduced, clients often get the wrong response type. In this case, it would result in getting the default response by the RDAP server. Implementers should add Accept to Vary. Should it be addressed by rdap-x draft ? We can add language deferring to RFC 9110 guidance on this. [ML] Do you mean that servers should implement Vary too ? If that is what they need to do. I don't think this changes any current caching strategies and deference to RFC 9110 is the proper guidance. My understanding of the current state of the Vary header is that it is mostly used by servers. That said, I have yet to see this as a real-world issue in the RDAP space. [ML] It could be an issue if we decide to start using content negotiation. The media type has not influenced the RDAP response so far. AFAIU, since the same URL may produce different responses based on the value of the Accept header, any cache that store responses needs to know that the header is important to determine if the cached response is valid or not and save clients from receiving a wrong response. Think it should be further investigated. Best, Mario -andy -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-jasdips-regext-rdap-geofeed
I support adoption. Mario Il 20/11/2023 15:36, Antoin Verschuren ha scritto: This is a formal adoption request for An RDAP Extension for Geofeed Data: https://datatracker.ietf.org/doc/draft-jasdips-regext-rdap-geofeed/ Please review this draft to see if you think it is suitable for adoption by REGEXT and comment to this message on the list, clearly stating your view. Optionally indicate if you are willing to contribute text, review text, or be a document shepherd. This Call For Adoption will close on Monday 4 December. If there are no objections, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact
Sorry. Forgot to reply to the mailing list. Thanks Andy for the heads up. Best, Mario Messaggio Inoltrato Oggetto: Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact Data: Fri, 17 Nov 2023 10:25:37 +0100 Mittente: Mario Loffredo A: Andrew Newton Hi Andy, please find my comments inline. Il 16/11/2023 19:58, Andrew Newton ha scritto: Mario, On Thu, Nov 16, 2023 at 9:28 AM Mario Loffredo wrote: Also, since you (and JG) have been arguing vehemently on your position, did you find a technical flaw in the rdap-x draft? Have you found a scenario where it does not work? [ML] Am not "arguing vehemently", I'm quietly explaining what does not completely convince me. Your proposal would have many implications on existing implementations and as many of them in the future, hence, it should be carefully evaluated. My apologies. I did not mean to offend. [ML] No worries. You didn't offend me. Here in the following some remarks/objections from my side sorted by relevance: - RDAP extensions are not only response extensions. So, even assuming that signaling preferences about response extensions is a matter of content negotiation, pure request extensions wouldn't theoretically be covered. How would they be manged ? Given that today there is no standardized means for a client to signal what extensions it prefers, I don't foresee a problem. They should probably be managed the same way as the others. Can you provide an example? [ML] Per what is stated in RFC 9083 Section 4.1, a pure request extension doesn't have to be included in the rdapConformance array of the related response when it is used in a query because the rdapConformance array is used to signal to the client only the extensions used in building the response. Per what is stated in Section3 of rdap-x draft, clients SHOULD give preference to the rdapConformance array in order to determine which extensions (including those requested ) were used to build the response. Let's suppose to use farv1_dnt in a query within an authenticated session. Have some questions: Should farv1 be included in the extensions parameter ? What should be the server response when it's not included in the extensions parameter but is used in the query string ? Supposing that farv1 has to be included in the extensions parameter when farv1_dnt is used, how should a client interpret that farv1 is missing in rdapConformance ? - AFAIK caches generally ignore Accept by default, so when content negotiation is first introduced, clients often get the wrong response type. In this case, it would result in getting the default response by the RDAP server. Implementers should add Accept to Vary. Should it be addressed by rdap-x draft ? We can add language deferring to RFC 9110 guidance on this. [ML] Do you mean that servers should implement Vary too ? - Requiring HTTP headers with media types makes it more difficult to test and explore the API using a browser. During development, you can launch the browser and easily see what the server is responding by simply using the address bar. When relying on content negotiation it's a bit more tricky, and you have to leverage plugins or cURL or anything else that can manipulate the headers. There are other very good development tools as well. I see people use Postman a lot, and httpie looks good as well. [ML] Yes. I have used Postman and Rester to test the implementation of token-oriented approach of rdap-open. A bit trickier than using the address bar. - (Minor) I wonder how much tricky it could be to get the value of the extensions parameter. At a quick glance, it doesn't look to me as straightforward as getting the value of a query parameter. I'd be curious to know if someone in the WG has already implemented it. This would depend on the server framework. But I can see about putting some code in the test server referenced in the draft. If not, then why do you insist on a path with known interoperability issues over a path without them? [ML] Because I personally see drawbacks in such an approach as well as possible inconsistencies in implying that lookup queries should not include query parameters. Anyway, if the WG agreed on this way to go, some normative language should be added somewhere to make it clear when query parameters are forbidden or unrecommended. I'm fine with that. I don't think the rdap-x draft is the right place. Perhaps the rdap-extensions draft. -andy -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] JSContact - SimpleContact discussion follow up
such a task to someone else. My apologies for the long post. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact
Hi Andy, please find my comments inline. Il 15/11/2023 14:41, Andrew Newton ha scritto: Mario (and JG), On Wed, Nov 15, 2023 at 5:17 AM Mario Loffredo wrote: [ML] About preserving query parameters in HTTP redirection, my opinion is that it depends on each application protocol built over HTTP. There are a ton of protocols on the web preserving query parameters in redirection and AFAIU there is nothing in RFC9110 stating that query parameters must be purged. On the contrary, RFC 9110 itself admits that a POST could be redirected and changed into a GET and I cannot imagine how it could be done without using query parameters. There is no disagreement on that. However, RFC 9110 does state that content negotiation is done with accept and content-type headers. If RDAP rules out preserving query parameters in redirection, this ought to be explicitly stated in section 5.2 of RFC 7480. The counter to that is that nowhere is it specified that they do generally survive redirects, there exists RFC language to instruct servers to ignore unknown query parameters, and there exist current deployments that do not preserve them. [ML] I agree with you on "unknown parameters" but RDAP has already defined many well known parameters for searches as well as lookups (i.e. dnt and qp in rdap-openid). Besides, there exist also current deployments that preserve them in redirection. For example, my RDAP server preserve the jscard parameter of rdap-jscontact in redirection. Since a normative language is missing, everyone is allowed to interpret RFC7480 and implement their own redirection strategy. Anyway, I wouldn't welcome such a policy for the following reasons: - RDAP is a relatively young protocol not yet largely used. At present, I couldn't exclude such a feature from being useful in future developments. - It would result in a sort of confusion between using query parameters in lookups and searches and also between different lookups. To be noted that rdap-openid, just gone through the WGLC, allows to specify two parameters which can be used in RDAP queries. - Bootstrapping is an optional feature. Would an RDAP provider be allowed to define a request custom lookup extension incuding query parameters if that kind of query will never be redirected ? The issue isn't that they are forbidden, the issue is that to use them in any scenario involving redirection, all servers participating in that redirection must behave in the same manner. At present, that is demonstrably untrue. [ML] As I wrote, the applicable query parameters are defined and well known by each HTTP-based application protocol. In RDAP, they have already been defined for both kinds of query and can be either ignored or implemented. As a consequence, I think it would be more consistent to allow for them in general, to preserve them in redirection and let the target servers to implement them rather than to try to delimit the cases where they are allowed and those where they aren't. With regard to the content negotiation, I personally interpreted that Accept header is used to negotiate a format involving the overall response rather than a portion, i.e. the contact information. Just to give an example: at last meeting, you mentioned CBOR. The use of CBOR would not be restricted to only the contact information. Anyway, I admit that this depends on different point of views. Instead, I am a bit doubtful about how the "extension" parameter is defined in the rdap-x draft but I confess that I'm not knowledgeable about media types so I asked an expert for a clarification. I'd be curious who he is and what he has to say. [ML] Nothing special. It was just for my better understanding of RFC6838. Also, since you (and JG) have been arguing vehemently on your position, did you find a technical flaw in the rdap-x draft? Have you found a scenario where it does not work? [ML] Am not "arguing vehemently", I'm quietly explaining what does not completely convince me. Your proposal would have many implications on existing implementations and as many of them in the future, hence, it should be carefully evaluated. Here in the following some remarks/objections from my side sorted by relevance: - RDAP extensions are not only response extensions. So, even assuming that signaling preferences about response extensions is a matter of content negotiation, pure request extensions wouldn't theoretically be covered. How would they be manged ? - AFAIK caches generally ignore Accept by default, so when content negotiation is first introduced, clients often get the wrong response type. In this case, it would result in getting the default response by the RDAP server. Implementers should add Accept to Vary. Should it be addressed by rdap-x draft ? - Requiring HTTP headers with media types makes it more difficult to test and explore the API using a browser. During development, you can launch the browser
Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact
Hi Andy, please find my comments below. Il 14/11/2023 14:38, Andrew Newton ha scritto: On Tue, Nov 14, 2023 at 2:53 AM Mario Loffredo wrote: The technical problems with the signaling have been discussed at length on this mailing list. A better and more generic solution has been proposed in the rdap-x-media-type draft. We never really discussed signaling during the session because the discussion was focused on the data model. The signaling proposed in rdap-jscontact section 3 cannot go forward as either standards track or experimental as it is incompatible with the current ecosystem. Why is it incompatible ? As first discussed, with you, on this mailing list: https://mailarchive.ietf.org/arch/msg/regext/k31GiGnrB4_Xu8c1pvatoT0oP9k/ -andy [ML] About preserving query parameters in HTTP redirection, my opinion is that it depends on each application protocol built over HTTP. There are a ton of protocols on the web preserving query parameters in redirection and AFAIU there is nothing in RFC9110 stating that query parameters must be purged. On the contrary, RFC 9110 itself admits that a POST could be redirected and changed into a GET and I cannot imagine how it could be done without using query parameters. If RDAP rules out preserving query parameters in redirection, this ought to be explicitly stated in section 5.2 of RFC 7480. Anyway, I wouldn't welcome such a policy for the following reasons: - RDAP is a relatively young protocol not yet largely used. At present, I couldn't exclude such a feature from being useful in future developments. - It would result in a sort of confusion between using query parameters in lookups and searches and also between different lookups. To be noted that rdap-openid, just gone through the WGLC, allows to specify two parameters which can be used in RDAP queries. - Bootstrapping is an optional feature. Would an RDAP provider be allowed to define a request custom lookup extension incuding query parameters if that kind of query will never be redirected ? With regard to the content negotiation, I personally interpreted that Accept header is used to negotiate a format involving the overall response rather than a portion, i.e. the contact information. Just to give an example: at last meeting, you mentioned CBOR. The use of CBOR would not be restricted to only the contact information. Anyway, I admit that this depends on different point of views. Instead, I am a bit doubtful about how the "extension" parameter is defined in the rdap-x draft but I confess that I'm not knowledgeable about media types so I asked an expert for a clarification. Best, Mario ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact
Hi Andy, Il 13/11/2023 19:30, Andrew Newton ha scritto: On Mon, Nov 13, 2023 at 12:28 PM wrote: Hi James, Likely I missed this part about splitting in the meeting - sorry for that. Can you be more specific? It is the mechanism described in 4. Transition Considerations? Shall it be only referring to jscontact or contact representation or to any transition of output representations? Here we also have draft-newton-regext-rdap-x-media-type-01 which would fulfil the same purpose, wouldn't it? Kind Regards, Pawel I too share the same confusion. My understanding was that both SimpleContact and RDAP JSContact would go experimental. I don't remember any talk about the signaling. The technical problems with the signaling have been discussed at length on this mailing list. A better and more generic solution has been proposed in the rdap-x-media-type draft. We never really discussed signaling during the session because the discussion was focused on the data model. The signaling proposed in rdap-jscontact section 3 cannot go forward as either standards track or experimental as it is incompatible with the current ecosystem. Why is it incompatible ? Best, Mario -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: I-D Action: draft-ietf-regext-rdap-reverse-search-26.txt
Hi everyone, just removed the "Description" field from the Reverse Search Mapping registry and both "Change Log" and "Implementation Status" section. No action from IANA is needed. Apart from possible text cleaning, think we are done. Best, Mario Messaggio Inoltrato Oggetto:[regext] I-D Action: draft-ietf-regext-rdap-reverse-search-26.txt Data: Mon, 13 Nov 2023 06:27:17 -0800 Mittente: internet-dra...@ietf.org Rispondi-a: regext@ietf.org A: i-d-annou...@ietf.org CC: regext@ietf.org Internet-Draft draft-ietf-regext-rdap-reverse-search-26.txt is now available. It is a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF. Title: Registration Data Access Protocol (RDAP) Reverse Search Authors: Mario Loffredo Maurizio Martinelli Name: draft-ietf-regext-rdap-reverse-search-26.txt Pages: 20 Dates: 2023-11-13 Abstract: The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-26 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-reverse-search-26 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___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: [Jsonpath] Online playground updated
For everyone who could be interested, here in the following an online JSONPath playground compliant with jsonpath-base spec. Best, Mario Messaggio Inoltrato Oggetto:[Jsonpath] Online playground updated Data: Mon, 2 Oct 2023 20:09:24 + (UTC) Mittente: Greg Dennis A: jsonp...@ietf.org I've updated my online playground, https://json-everything.net/json-path, to include the various options I support through the library. The default behavior is specification compliance. The options allow various deviations, generally ones that we discussed and rejected during spec development. Greg-- JSONpath mailing list jsonp...@ietf.org https://www.ietf.org/mailman/listinfo/jsonpath ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Roman Danyliw's No Objection on draft-ietf-regext-rdap-reverse-search-25: (with COMMENT)
Hi Roman, again my reponses below. Il 25/09/2023 22:55, Roman Danyliw ha scritto: Hi Mario! Thanks for the response. Response inline … *From:* Mario Loffredo *Sent:* Friday, September 1, 2023 6:50 AM *To:* Roman Danyliw ; The IESG *Cc:* draft-ietf-regext-rdap-reverse-sea...@ietf.org; regext-cha...@ietf.org; regext@ietf.org; t...@apnic.net *Subject:* Re: Roman Danyliw's No Objection on draft-ietf-regext-rdap-reverse-search-25: (with COMMENT) Hi Roman, please find my comments below. Il 30/08/2023 14:16, Roman Danyliw via Datatracker ha scritto: Roman Danyliw has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ -- COMMENT: -- Thank you to Tero Kivinen for the SECDIR review. Thanks for address my DISCUSS feedback. I support Lars Eggert's DISCUSS position. == ** Section 1. The first objection concerns the potential risks of privacy violation. Where are these privacy concerns summarized? Could a reference be provided? [ML] Guess you think your remark hasn't yet been addressed by the new version. Considering that the implications on privacy are presented in more detail in the "Privacy Considerations" section, could it be enough to rewrite that sentence as in the following ? (*) The first objection concerns the potential risks of privacy violations resulting from the use ofpersonal data and the detection of facts about an individual when the requestor is not supported by lawful basis. I'm not aware of any document describing those concerns. When I wrote the "Privacy Considerations" section, I started from the threats listed in RFC6973 and I tried to identify those which could fit in with the reverse search. Afterwards, RegExt considered that section exhaustive enough to conclude the discussion about the privacy concerns. [Roman] The Privacy Considerations and the inline text make the issue clear. I was reacting to the following text: its availability as a standardized Whois [RFC3912] capability has been objected to for two main reasons, which now don't seem to conflict with an RDAP implementation. [Roman] My recommendation was that if there was a way to cite the objections to whois, it would be helpful (instead of asserting there were objections without a reference). If this is not easy to do, then please ignore the feedback. [ML] Have repeatedly searched the web for some documents (preferably by ICANN or CENTR or some other forum of registries) about privacy concerns connected with Reverse Whois but all of those I found talk generally about "privacy concerns". This is the reason why I tried to summarize them in the sentence above (*). Anyway, if there is someone in RegExt who knows a suitable reference, I would be happy to include it in the document. Best, Mario Thanks, Roman ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-01.txt
} ... } Kind Regards, Pawel Am 31.08.23 um 12:02 schrieb Andrew Newton: Hi all, We have posted an update to Simple Contact. Here are the summary of the changes: * removed structured names * removed structured addresses * fixed ISO-3166-2 usage * removed the "masked" property * updated the example * added a section on linking to vcard / jcard / jscontact Overall, this simplifies the draft significantly, which was the overall feedback from IETF 117. -andy -- Forwarded message - From: Date: Thu, Aug 31, 2023 at 5:56 AM Subject: New Version Notification for draft-newton-regext-rdap-simple-contact-01.txt To: Andy Newton, Tom Harrison A new version of Internet-Draft draft-newton-regext-rdap-simple-contact-01.txt has been successfully submitted by Andy Newton and posted to the IETF repository. Name: draft-newton-regext-rdap-simple-contact Revision: 01 Title:RDAP Simple Contact Date: 2023-08-31 Group:Individual Submission Pages:11 URL:https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-01.txt Status:https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/ HTML:https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-01.html HTMLized:https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-simple-contact Diff:https://author-tools.ietf.org/iddiff?url2=draft-newton-regext-rdap-simple-contact-01 Abstract: This document describes an extension to the Registry Data Access Protocol for entity contact data using basic JSON values, objects, and arrays. The data model defined by this document is purposefully limited to the data in-use by Internet Number Registries and Domain Name Registries and does not attempt to model the full data-set that can be expressed with other contact models such as jCard or JSContact. The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext Pawel Kowalik Head of Product Management -- DENIC eG, Theodor-Stern-Kai 1, 60596 Frankfurt am Main, GERMANY E-Mail:pawel.kowa...@denic.de, Fon: +49 69 27235-105, Fax: -235 https://www.denic.de Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main) Vorstand: Thomas Keller, Martin Küchenthal, Andreas Musielak, Sebastian Röthler Vorsitzender des Aufsichtsrats: Daniel Rink Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main Allgemeiner Hinweis zur Erfüllung unserer Informationspflichten gemäß Art. 13, Art. 14 DS-GVO: Informationen zur Verarbeitung personenbezogener Daten durch DENIC finden Sie unterhttps://www.denic.de/datenverarbeitung-allgemein/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Hi Rob, No problem, don't mention it :-) Best, Mario Il 08/09/2023 15:35, Rob Wilton (rwilton) ha scritto: Hi Mario, Sorry to be slow to get back you. I’ve checked the changes in -25 against my comments and it all looks good to me. I’ve cleared my discuss. Regards, Rob *From:*iesg *On Behalf Of *Mario Loffredo *Sent:* 28 August 2023 08:57 *To:* Rob Wilton (rwilton) ; The IESG *Cc:* draft-ietf-regext-rdap-reverse-sea...@ietf.org; regext-cha...@ietf.org; regext@ietf.org; t...@apnic.net *Subject:* Re: [regext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT) Hi Robert, need to partially correct my comment about the content of table in Section 12.2.4.2. The "Reference" field is already defined for the "Reverse Search Mapping" registry and for all the entries of that registry the value is the same as that for the entries of the "Reverse Search" registry as it is explained in the second paragraph of Section 12.2.4.2. The "Reference" field in the "Reverse Search Mapping" registry is required to store the link to the documentation supporting the given mapping. The "PropetyPath" field allows the requestor to describe the mapping formally and unambiguously. Therefore, thinking back, there's no need to introduce a "Description" property for that registry. Anyway, if you think the "Description" field should also be included to provide a brief description of the mapping, I'll add it to both 12.2.4.1 and 12.2.4.2 Sections. Looking forward to you reply about this and other points. Best, Mario Il 24/08/2023 15:48, Mario Loffredo ha scritto: Hi Robert, thanks a lot for your review. Please find my comments inline. Il 23/08/2023 15:06, Robert Wilton via Datatracker ha scritto: Robert Wilton has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ -- DISCUSS: -- Hi, Flagging part of the IANA considerations as a DISCUSS, but I think that this should be easy to resolve: (1) p 11, sec 12.2.1. Creation of the RDAP Reverse Search Registries These registries follow the Specification Required process as defined in Section 4.5 of [RFC8126]. The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability. References are not limited only to RFCs and simple definitions could be described in the registries themselves. I'm not sure that "simple definitions could be described in the registries themselves" is consistent with the "Specification Required" policy chosen above. [ML] You are right. I'll change that sentence as in the following: References are not limited only to RFCs but can also locate document published outside of the RFC path, including informal documentation. Does it work for you ? -- COMMENT: -- [I support John's discuss on normative references.] I also have some other comments that you may wish to consider: (2) p 14, sec 12.2.4.2. Initial Content +==+==+ | Property | Property Path | +==+==+ | fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3] | +--+--+ | handle | $.entities[*].handle | +--+--+ | email | $.entities[*].vcardArray[1][?(@[0]=='email')][3] | +--+
Re: [regext] Roman Danyliw's No Objection on draft-ietf-regext-rdap-reverse-search-25: (with COMMENT)
Hi Roman, please find my comments below. Il 30/08/2023 14:16, Roman Danyliw via Datatracker ha scritto: Roman Danyliw has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ -- COMMENT: -- Thank you to Tero Kivinen for the SECDIR review. Thanks for address my DISCUSS feedback. I support Lars Eggert's DISCUSS position. == ** Section 1. The first objection concerns the potential risks of privacy violation. Where are these privacy concerns summarized? Could a reference be provided? [ML] Guess you think your remark hasn't yet been addressed by the new version. Considering that the implications on privacy are presented in more detail in the "Privacy Considerations" section, could it be enough to rewrite that sentence as in the following ? The first objection concerns the potential risks of privacy violations resulting from the use ofpersonal data and the detection of facts about an individual when the requestor is not supported by lawful basis. I'm not aware of any document describing those concerns. When I wrote the "Privacy Considerations" section, I started from the threats listed in RFC6973 and I tried to identify those which could fit in with the reverse search. Afterwards, RegExt considered that section exhaustive enough to conclude the discussion about the privacy concerns. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] JSON Schema for RDAP RFC-9083
Hi Scott, as just posted by Gavin, have already worked on a JSON Schema for RDAP and used it to build a kind of crawler which was able to validate the RDAP responses against RFC7483. Obviously, have no problem to collaborate with everyone is willing to define a JSON Schema for RDAP but think we should consider that, as you wrote, JSON Schema is not an RFC. AFAIU, the definition of a standard JSON data description language has been a controversial matter for long. To my knowledge, the only DDL published as RFC that could work is CDDL [RFC8610]. It was primarily created for CBOR but it works for JSON too. Best, Mario Il 31/08/2023 16:58, Hollenbeck, Scott ha scritto: There is no RFC that I can find that describes JSON Schema. That’s not surprising, since when I did some reading on the web site described below I found references to multiple expired I-Ds: https://json-schema.org/specification.html The lack of a formal specification certainly contributed to there being nothing said in 9083, but it’s been a while and I just don’t remember the topic ever coming up. There’s no mention of “JSON Schema” in the mailing list archive that I could find. It might or not be valuable to develop a schema for RDAP responses. You should describe your goals first, and then we can discuss if/how JSON Schema helps meet those goals. Scott *From:* Sammy Mishal *Sent:* Wednesday, August 30, 2023 1:55 PM *To:* regext@ietf.org *Cc:* Hollenbeck, Scott ; dev-t...@d3serve.xyz; z...@d3serve.xyz *Subject:* [EXTERNAL] JSON Schema for RDAP RFC-9083 *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. Dear Regext Working Group of IETF, We are working on a product that depends on JSON response from RDAP protocol. We came across RFC-9083; realizing it doesn't specify a JSON Schema format (https://json-schema.org/ <https://secure-web.cisco.com/1fJJgFqINFVhoOA_5rjaXYcecxkx8XGThFdxcJBmvR9cOnA1HxlcCln5hM2QQBTL_TkxGwUGYBWK_LefLCGVe9kWku0lCi5u3ExqJltJPZfJ-m97JWEDeAF34mbsOnDhKmrmbjSm5mL7HHqjFnnZNctlsDfl_lIxD9eR3o-fv9gHxSyRQBmOUn5sKfhYx296ZW0n8J-5QFYYTDXIdc-AkdL4izdjA14fxoKFKEsue7y9cK-4scKsLmjCzPGhOgZxaLCu2DXGSdlpl7bRE4v2n-CjlW9irm259SoeTO1m7NulRPN3nrCld1tyGut55qUDJg48t9N5V93qmh41E6-ZlkQ/https%3A%2F%2Fjson-schema.org%2F>). Do you know if there is any RFC specifying the JSON schema format for RDAP response? If not, any rationale why not, or is it a good idea for us to contribute a JSON schema RFC? Sami Mis'hal and Victor Zhou, D3Serve Labs Email: dev-t...@d3serve.xyz ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: I-D Action: draft-ietf-regext-rdap-reverse-search-25.txt
Hi reviewers, this version should address most, hopefully all, of your remarks. Please see the Change Log section for more details. Looking forward to your reply. Best, Mario Messaggio Inoltrato Oggetto:[regext] I-D Action: draft-ietf-regext-rdap-reverse-search-25.txt Data: Wed, 30 Aug 2023 01:32:48 -0700 Mittente: internet-dra...@ietf.org Rispondi-a: regext@ietf.org A: i-d-annou...@ietf.org CC: regext@ietf.org Internet-Draft draft-ietf-regext-rdap-reverse-search-25.txt is now available. It is a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF. Title: Registration Data Access Protocol (RDAP) Reverse Search Authors: Mario Loffredo Maurizio Martinelli Name: draft-ietf-regext-rdap-reverse-search-25.txt Pages: 24 Dates: 2023-08-30 Abstract: The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-25 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-reverse-search-25 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___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Hi Robert, need to partially correct my comment about the content of table in Section 12.2.4.2. The "Reference" field is already defined for the "Reverse Search Mapping" registry and for all the entries of that registry the value is the same as that for the entries of the "Reverse Search" registry as it is explained in the second paragraph of Section 12.2.4.2. The "Reference" field in the "Reverse Search Mapping" registry is required to store the link to the documentation supporting the given mapping. The "PropetyPath" field allows the requestor to describe the mapping formally and unambiguously. Therefore, thinking back, there's no need to introduce a "Description" property for that registry. Anyway, if you think the "Description" field should also be included to provide a brief description of the mapping, I'll add it to both 12.2.4.1 and 12.2.4.2 Sections. Looking forward to you reply about this and other points. Best, Mario Il 24/08/2023 15:48, Mario Loffredo ha scritto: Hi Robert, thanks a lot for your review. Please find my comments inline. Il 23/08/2023 15:06, Robert Wilton via Datatracker ha scritto: Robert Wilton has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ -- DISCUSS: -- Hi, Flagging part of the IANA considerations as a DISCUSS, but I think that this should be easy to resolve: (1) p 11, sec 12.2.1. Creation of the RDAP Reverse Search Registries These registries follow the Specification Required process as defined in Section 4.5 of [RFC8126]. The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability. References are not limited only to RFCs and simple definitions could be described in the registries themselves. I'm not sure that "simple definitions could be described in the registries themselves" is consistent with the "Specification Required" policy chosen above. [ML] You are right. I'll change that sentence as in the following: References are not limited only to RFCs but can also locate document published outside of the RFC path, including informal documentation. Does it work for you ? -- COMMENT: -- [I support John's discuss on normative references.] I also have some other comments that you may wish to consider: (2) p 14, sec 12.2.4.2. Initial Content +==+==+ | Property | Property Path| +==+==+ | fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3]| +--+--+ | handle | $.entities[*].handle | +--+--+ | email| $.entities[*].vcardArray[1][?(@[0]=='email')][3] | +--+--+ | role | $.entities[*].roles | +--+--+ Would it be helpful for this table to include the "Description" and "Reference" properties? [ML] Do you mean the "Description" and "Reference" related to the specific mapping for the reverse search property or those related to the reverse search property ? In the latter case they are already included in Table 2 and Table 1 respectively. In the first case, they are missing and must be first added to the "RDAP Reverse Search Mapping Registry". Since there might be specifications proposing a diffierent maping for an existing reverse search property it sounds reasonable to me to add both of them. Minor level comments: (3) p 3, sec 1. Introduction The protocol described in this specification aims to extend the RDAP query capabilities and response to enable reverse search based on the relationshi
Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Hi Amanda, thanks a lot for your quick reply. You're right. I can remove that sentence. Thanks a lot, Mario Il 25/08/2023 00:17, Amanda Baber ha scritto: Hi Mario, I see that the new text is "References are not limited only to RFCs but can also locate document published outside of the RFC path, including informal documentation." For IANA's purposes, this sentence isn't necessary, as the Specification Required policy was specifically meant to encompass non-RFC documentation (see Section 4 of RFC 8126 for registration procedure definitions), but no problem at all with including it. Thanks, Amanda On 8/24/23, 9:18 AM, "iesg on behalf of Mario Loffredo" wrote: Hi Amanda, Il 23/08/2023 19:51, Amanda Baber ha scritto: > Regarding the use of a brief description in the registry itself as the "Specification" in "Specification Required": I missed it this time, but we ran into this same question with draft-ietf-calext-jscalendar-21, and FWIW, Barry Leiba recommended to the author that the registration procedure be changed to Expert Review. Please see my response to Robert Wilton's remarks. Think that changing the text as I proposed could solve the problem. I'm sure that Andy and Scott as DEs would like to receive a specification supporting a request for the registration of new reverse search properties or new mappings. Therefore, I would like to make the IANA Considerations section compliant to the Specification Required policy. Best, Mario > > Thanks, > Amanda > > On 8/23/23, 6:07 AM, "iesg on behalf of Robert Wilton via Datatracker" wrote: > > Robert Wilton has entered the following ballot position for > draft-ietf-regext-rdap-reverse-search-24: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTv8R0bod8$ [ietf[.]org] > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/__;!!PtGJab4!_Nbv4aqGp36yMsh4urjgozBK2A_rIEY2i19RDAgHNiDersZRIlzMkjluoUFmtpZqiPm4XoiUsqnZRMTvYBEfpd4$ [datatracker[.]ietf[.]org] > > > > -- > DISCUSS: > -- > > > > Hi, > > Flagging part of the IANA considerations as a DISCUSS, but I think that this > should be easy to resolve: > > (1) p 11, sec 12.2.1. Creation of the RDAP Reverse Search Registries > > These registries follow the Specification Required process as defined > in Section 4.5 of [RFC8126]. > > The designated expert should prevent collisions and confirm that > suitable documentation, as described in Section 4.6 of [RFC8126], is > available to ensure interoperability. References are not limited > only to RFCs and simple definitions could be described in the > registries themselves. > > I'm not sure that "simple definitions could be described in the registries > themselves" is consistent with the "Specification Required" policy chosen above. > > > -- > COMMENT: > -- > > [I support John's discuss on normative references.] > > I also have some other comments that you may wish to consider: > > (2) p 14, sec 12.2.4.2. Initial Content > > +==+==+ >| Property | Property Path | > +==+==+ >| fn | $.entities[*].vcardArray[1][?(@[0]=='fn')][3] | > +--+---
Re: [regext] Opsdir last call review of draft-ietf-regext-rdap-reverse-search-24
Hi Tim, again my responses below. Il 24/08/2023 10:02, Tim Chown ha scritto: Hi, On 22 Aug 2023, at 10:50, Mario Loffredo wrote: Hi Tim, thanks a lot for your review. Please find my comments inline I’ll answer the privacy point in response to Andy’s email. Il 21/08/2023 20:27, Tim Chown via Datatracker ha scritto: Reviewer: Tim Chown Review result: Not Ready It seems the text in paragraph 3 of the Introduction is saying it’s not an issue as RDAP search queries already exist. But looking at related RFCs I see examples where specific controls (rate limiting, response codes for too many queries, etc) are described. So I think the concern is clear, rather the text should state that controls can be implemented, or indeed SHOULD be, later in the document. [ML] The concern is about RDAP searches in general, not specifically about the reverse searches. In addition, the reverse search is not new in RDAP. RFC 9082 defines queries to search for domains starting for a detail of the associated name servers. I would assume one aspect of the concern is the larger volume of queries that is likely to follow, and in particular efforts to recover potential PII (whether it is actually available or not). So both a general higher volume of queries, but also a level of additional ‘harvesting’ activity. I think that’s where some text could be added, and covered by similar protections as described for existing queries. [ML] The largest volume of queries will likely be towards the public endpoints of the RDAP services. In general, the endpoints protected by authorization mechanisms, as reverse searches are expected to be, are not accessed frequently. But if protected and public resources coexist in the same service, this may result in increasing the risk of attacks to the protected resources and decreasing the efficiency of the service for accredited users. One solution is to dedicate a specific path segment to the authenticated endpoints (e.g. https://example.com/rdap/auth/... instead of https://example.com/rdap/...). It permits: - to easily implement the support for authentication/authorization since, for example, most known OpenID implementations offers some kind of software adapters protecting a given path (or all the paths starting with a given prefix); - to configure a proxy routing the requests to two different backend servers, one serving the anonymous requests to public endpoints and one serving the authenticated requests to the protected endpoints, and eventually adding to the latter server some security services provided by other protocol layers such as certificates and IP whitelisting. Does the considerations above address your remark ? Should I add them to the Implementation Considerations section ? This document just aims to describe a formal query model addressing every kind of reverse search based on the relationships between the RDAP objects. RFC 8977 and RFC 8982 already provide guidance to implementers on how to make searches more sustainable for both clients and servers but, obviously, RDAP providers can implement additional measures with the same purpose. That said, Section 10 already includes text recommending to use techniques speeding up the data retrieval and mitigating the risks of performance degradation. Hence, IMO, it already addresses your remark. The text further into the document helps, but the text I the Intro ignores this; it should forward point to that. [ML] Does it work for you if I add text in the Introduction section stating that the implementation of a reverse search feature might request additional effort in processing the queries and making them sustainable for the server (see Implementation Considerations) and improving the security level (see Security Considerations) ? Finally, related, I welcome the details of implementations in the draft, but I note they are ‘alpha’ state. I’m curious as to their potential progression, and what testing at any scale may have bene done. [ML] At .it, we have implemented only the reverse search based on domain-entity relationship and it's unaccessible to public users. Presently it's available to registrar users under the conditions explained in my first comment and we plan to make it available to authorities soon. ARIN and APNIC have described in draft-ietf-regext-rdap-rir-search <https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/> a potential usage of the reverse search in their own RDAP servers. OK, thanks. This seems to boil down to a solution that is technically fine, from my level of knowledge of RDAP, but where the use cases need to be considered by the IESG in their evaluation. [ML] The possible use cases are reported in the Introduction section. Best, Mario Tim Best, Mario Best wishes, Tim -- Dott. Mario Loffredo Senior Technologist Technological Unit “Digital Innovation” Institute of Infor
Re: [regext] [Ext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
t), and the rest of the text was moved into a "Background" subsection of the introduction. (4) p 7, sec 8. Reverse Searches Based on Entity Details Reverse search property: fn RDAP member path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3] Reference: Section 6.2.1 of [RFC6350] A minor issue, but it wasn't immediately obvious to me what 'fn' is - I initially presumed that it meant function, so I was wondering if some more text would be helpful here, and/or perhaps in the IANA registry that you are creating. Regards, Rob ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Éric Vyncke's No Objection on draft-ietf-regext-rdap-reverse-search-24: (with COMMENT)
Hi Éric, thanks a lot for your review. Best, Mario Il 23/08/2023 16:15, Éric Vyncke via Datatracker ha scritto: Éric Vyncke has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ -- COMMENT: -- Thank you for the work put into this document. While my review did not identity any issues, I am supporting Lars' & John's DISCUSS points. Special thanks to Tom Harrison for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Robert Wilton's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
eneric model. 1.1 Background Reverse Whois is a service provided by many web applications that allows users to find domain names owned by an individual or a company starting from the owner's details, such as name and email. Even if it has been considered useful for some legal purposes (e.g. uncovering trademark infringements, detecting cybercrimes), its availability as a standardized Whois capability has been objected to for two main reasons, which now don't seem to conflict with an RDAP implementation. . . . Currently, RDAP does not provide any means for a client to search for the collection of domains associated with an entity [RFC9082]. A query (lookup or search) on domains can return the array of entities related to a domain with different roles (registrant, registrar, administrative, technical, reseller, etc.), but the reverse operation is not allowed. Only reverse searches to find the collection of domains related to a nameserver (ldhName or ip) can be requested. Since an entity can be in relationship with any RDAP object [RFC9083], the availability of a reverse search as largely intended can be common to all the object classes allowed for search. Through a further step of generalization, the meaning of reverse search in the RDAP context can be extended to include any query for retrieving all the objects in relationship with another matching a given search pattern. Can you please confirm that it would work for you ? (4) p 7, sec 8. Reverse Searches Based on Entity Details Reverse search property: fn RDAP member path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3] Reference: Section 6.2.1 of [RFC6350] A minor issue, but it wasn't immediately obvious to me what 'fn' is - I initially presumed that it meant function, so I was wondering if some more text would be helpful here, and/or perhaps in the IANA registry that you are creating. [ML] FN is a property of the vCard format [RFC6350] representing the contact name. The JSON format for the vCard data, namely jCard [RFC7095], is used in RDAP responses [RFC9083] to represent contact information (see the member "vcardArray" in the JSONPath expression) jCard specification states that the property names should be in lowercase. The name 'fn' is also used in RDAP as query parameter for seacrhing contacts by name [RFC9082]. Besides being well-known to RDAP operators, think that the value of the "Description" field in the "RDAP Reverse Search" registry makes it clear enough the meaning of the "fn" reverse search property. Best, Mario Regards, Rob ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] John Scudder's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS)
Hi John, thanks a lot for your review. Please find my comments below. Il 22/08/2023 22:55, John Scudder via Datatracker ha scritto: John Scudder has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ -- DISCUSS: -- Thanks for this document. I have one concern, which should be easy to address. It looks as though draft-ietf-jsonpath-base should be a Normative reference. In fact, this is explicitly mentioned in the shepherd writeup (thank you!): > 15. Should any informative references be normative or vice-versa? See the [IESG > Statement on Normative and Informative References][16]. JSON Paths are depended on normatively in the document, but the reference for them is to I-D.ietf-jsonpath-base, which is why that reference is informative. (This is in keeping with e.g. RFC 8977, though in that case the reference was to the original description of the JSON Path behaviour at https://goessner.net/articles/JsonPath/.) However, that rationale doesn't make sense to me. If a normative reference is a downref, "just stick it in the informative references section instead" is not the appropriate fix, the usual thing is to keep it in the normative references and then the RFC Editor deals with the mismatch by holding off on publication of the dependent document, until the dependency is published (a so-called "cluster"). In this case, draft-ietf-jsonpath-base is on the same IESG agenda as draft-ietf-regext-rdap-reverse-search is, so there isn't even much reason to worry that draft-ietf-regext-rdap-reverse-search will be stalled for long if at all, the two will likely move together. The easiest way to resolve this DISCUSS would be to change the reference to Normative. If for some reason that's considered unacceptable, I'd appreciate a discussion explaining why, and why "make it an informative reference" should be acceptable. [ML] I fully agree with you. That reference is informative because I literally interpreted Note 4 but it should be normative. I'll move it to the Normative References. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Roman Danyliw's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Hi Roman, thanks a lot for your review. Please find my comments inline. Il 22/08/2023 21:20, Roman Danyliw via Datatracker ha scritto: Roman Danyliw has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ -- DISCUSS: -- ** Section 13 In general, given the sensitivity of this functionality, it SHOULD be accessible to authorized users only, and for specific use cases only. If this data is considered sensitive, why would unauthorized users be permitted to access it (as permitted by use of SHOULD and not a MUST). [ML] The point is that it's not always sensisitive. Therefore, I cannot write MUST because there might be cases where this functionality could also be accessible to anonymous users without causing a privacy violation. Providing this feature to unauthorized users when it's based on a sensitive information would result in breaking a law rather than breaking a protocol. Therefore, I'm absolutely sure that no RDAP provider will make it available to users who are not legitimate to use it. Anyway, would it sound better if I changed that sentence into the following ? /In those cases where this functionality makes use of sensitive information, it MUST be accessible to //authorized users only, and for specific use cases only./ ** Section 13 Providing reverse search in RDAP carries the following threats as described in [RFC6973]: * Correlation * Disclosure * Misuse of information Therefore, RDAP providers need to mitigate the risk of those threats by implementing appropriate measures supported by security services (see Section 14). Thank you for explicitly including a privacy considerations section to outline the associated risks. Can the text please be more specific in linking these real threats with the proposed mitigations referenced in Section 14? For example, if one is mitigating against “misuse of information” is that by an authenticated/authorized or authenticated user? Is some kind of authentication/authorization required for this class of invocation of RDAP? RFC7481 presents options but not much MTI. How is “correlation” being mitigated? What is “disclosure” in this case? How is it mitigated? [ML] Correlation and disclosure can be mitigated by minimizing functionalities and data within identity management (i.e. Role-Based Access Control) and keeping data opaque to unauthorized users by redaction. Mis-use can be mitigated by requiring the purpose of the request (i.e. Purpose-Based Access Control). Two approaches can be followed: - Full Trust: the registry trusts the fairness of an accredited user (e.g. a police officer, an authority). The requestor is always legitimated to submit his requests for a legal purpose but it might also be required to clearly specify the purpose as either an attribute of the user (e.g. a specific OpenID claim) or a query parameter - Zero Trust: the registry requires documents assessing that the requestor is legitimated to submit a given request no matter the declared purpose. It can be implemented by assigning the requestor with temporary OpenID credentials linked to the given request and describing the request as an attribute of the user (i.e. Time-Based & Attribute-Based Access Control) Could the text above work for you ? If you need more information about such mitigation measures, please see the presentation I gave at IETF110 (https://datatracker.ietf.org/meeting/110/materials/slides-110-regext-5i-mario-loffredo-draft-ietf-regext-rdap-reverse-search-00). If it's worthwhile, I can also add text extracted from the conclusions of that presentation: - To mitigate privacy threats, RDAP providers MUST set up an AAA infrastructure operating in compliance with regulations about privacy protection in force in their countries - Consequently, RDAP providers SHALL implement authorization rules increasingly stringent: from a policy based merely on roles, to requiring the request purpose, till to assigning the user with temporary credentials and related grants that are scope limited - Even if searches on contacts’ information might be made publicly available on those contacts who gave the consent for publishing, RDAP providers are RECOMMENDED to allow those searches only to authorized u
Re: [Gen-art] Genart last call review of draft-ietf-regext-rdap-reverse-search-24
Hi Susan, thanks for the additional feedback. Again my comments below. Il 22/08/2023 15:19, Susan Hares ha scritto: Mario: Thank you for your response. You are correct. My editorial #3 should be: New: /However, the core RDAP specifications already define search queries with similar processing requirements so the basis of this objection is not clear./ [ML] Perfect. I noticed that the OPS-DIR review indicated operational difficulties that I did not consider: https://datatracker.ietf.org/doc/review-ietf-regext-rdap-reverse-search-24-opsdir-lc-chown-2023-08-21/ For my own curiosity and learning, I found Tim Chown’s two questions were import: 1) why did you state “should” instead of MUST for HTTPS? Excerpt from Tim Chown’s review: The Privacy Considerations section also quite rightly talks about HTTPS being required for reverse search. But I’m curious as to why the reverse search functionality SHOULD only be accessible to authorised users for specific use cases, rather than MUST? And is that ‘should’ in paragraph two of the Privacy Considerations a SHOULD? I wonder also here whether as per other RDAP specs I’ve looked at as part of this review there is the privacy of the querier to be considered, but I suppose if specific authorization is required then that is an unrealistic expectation? [ML] The privacy concern is about the use of PII to discover facts about individuals as contacts associated to RDAP objects. Hence it's not the privacy of the requestor that must be preserved but rather that of individuals whose information is stored in the registry database. For example, using an individual's email address as the basis for a reverse search to obtain all the domains of that holder. In general, unless the individual has given his consent for publishing, the sensitive information gets redacted in the RDAP response when the query is submitted by an anonymous user. As a consequence, it's obvious that anonymous users can't submit a reverse search based on it. In addition, RDAP searches are usually not allowed to anonymous users because of their impact on processing resources. But an RDAP server can be suported by authorization mechanims to permit some authorized and legitimate users to submit searches and, specifically, reverse searches. 2) Should you include comments on rate limiting of reverse RDAP? [ML] Rate limiting is a topic connected to the handling of RDAP searches in general, hence, not specifically to that of reverse searches. Besides, every RDAP provider can implement different strategies to limit the query rate. There are a number of measures coming in my mind but all of them are based on my personal experience. My opinion is that, if there's ever a RegExt draft about best practices in providing RDAP searches, that document could be the right place to address rate limiting. Hope my responses could be satisfying. Best, Mario Thank you, Sue Hares *From:*Mario Loffredo *Sent:* Tuesday, August 22, 2023 5:27 AM *To:* Susan Hares ; gen-art@ietf.org *Cc:* draft-ietf-regext-rdap-reverse-search@ietf.org; last-c...@ietf.org; reg...@ietf.org *Subject:* Re: Genart last call review of draft-ietf-regext-rdap-reverse-search-24 Hi Susan, thanks a lot for your review. Please find my comments inline. Il 21/08/2023 22:14, Susan Hares via Datatracker ha scritto: > Reviewer: Susan Hares > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-regext-rdap-reverse-search-?? > Reviewer: Susan Hares > Review Date: 2023-08-21 > IETF LC End Date: 2023-08-11 > IESG Telechat date: 2023-08-24 > > Summary: The text is readable even for a novice in RDAP. > I appreciated how sections 13 and 14 discussed the tension between the need for > operational data and the need for the privacy of personal information. It is > important that registry operators who use this technology to provide reverse > RDAP provide clear communication to the following groups of people: a) the > people registering this data, b) security personnel within the registry > operator providing the data, c) any people allowed to access the data, and d) > other registries that may import data from this registry. > > I find this text to be sufficient. I will please to see the security-DIR > review found it ready to publish. > > Nits/editorial comments: > Nits: > Nit-#1: Section 1: It would be helpful to the naive reader to provide an IETF > link for whois in section 1
Re: [regext] Lars Eggert's Discuss on draft-ietf-regext-rdap-reverse-search-24: (with DISCUSS and COMMENT)
Hi Lars, thanks a lot for your review. Please find my comments inline. Il 22/08/2023 12:48, Lars Eggert via Datatracker ha scritto: Lars Eggert has entered the following ballot position for draft-ietf-regext-rdap-reverse-search-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ -- DISCUSS: -- # GEN AD review of draft-ietf-regext-rdap-reverse-search-24 CC @larseggert Thanks to Susan Hares for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/Pb3ulFRTmqoQ5FOhkYGLHrZ1zVE). ## Discuss (For discussion in the IESG, i.e., no action required from the authors.) This is likely me not understanding something, but I'd appreciate if someone could explain where this document fits into the current REGEXT charter scope? -- COMMENT: -- ## Comments ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `natively`; alternatives might be `built-in`, `fundamental`, `ingrained`, `intrinsic`, `original` [ML] Sorry I was not aware of it. Replaced "natively supported" with "built-in" ;-) ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Outdated references Document references `draft-ietf-jsonpath-base-17`, but `-19` is the latest available revision. [ML] The document makes use of the citation https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-jsonpath-base.xml that properly shows '-19' as the last revision of jsonpath-base. Version '-17' is reported instead when the document is rendered. Could it be a bug of the rendering tool ? ### Grammar/style Section 12.2.3.1, paragraph 5 ``` | entity search based on the full name (a.k.a | | | formatted name) of an as ^ ``` The abbreviation/initialism is missing a period after the last letter. [ML] Good catch. Fixed. Best, Mario ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Genart last call review of draft-ietf-regext-rdap-reverse-search-24
Hi Susan, thanks a lot for your review. Please find my comments inline. Il 21/08/2023 22:14, Susan Hares via Datatracker ha scritto: Reviewer: Susan Hares Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-regext-rdap-reverse-search-?? Reviewer: Susan Hares Review Date: 2023-08-21 IETF LC End Date: 2023-08-11 IESG Telechat date: 2023-08-24 Summary: The text is readable even for a novice in RDAP. I appreciated how sections 13 and 14 discussed the tension between the need for operational data and the need for the privacy of personal information. It is important that registry operators who use this technology to provide reverse RDAP provide clear communication to the following groups of people: a) the people registering this data, b) security personnel within the registry operator providing the data, c) any people allowed to access the data, and d) other registries that may import data from this registry. I find this text to be sufficient. I will please to see the security-DIR review found it ready to publish. Nits/editorial comments: Nits: Nit-#1: Section 1: It would be helpful to the naive reader to provide an IETF link for whois in section 1. [ML] OK. Looks better to move up the link to RFC 3912 to the sentence including "... standardized Whois capability ... ". Editorial comments: English textual comments to improve readability. #1 Section 1, paragraph 1 Old:/Since RDAP consequently permits a reverse search implementation complying with privacy protection principles, this objection is not well-founded./ New:/Since RDAP consequently permits a reverse search implementation complying with privacy protection principles, this first objection is not well-founded./ [ML] OK. #2 Section 1: paragraph 2 Old:/The other objection to the implementation of a reverse search capability has been connected with its impact on server processing./ New:/The second objection to the implementation of a reverse search capability has been connected with its impact on server processing./ [ML] OK. #3, Section 1: paragraph 2 Old: / However, the core RDAP specifications already define search queries, with similar processing requirements, so the distinction on which this objection is based is not clear./ New: /However, the core RDAP specifications already define search queries with similar processing requirements so the basis of this objection is based is not clear./ [ML] Do you mean "... so the basis of this objection is not clear" ? Section 3, paragraph 2 Old: /All of the reverse searches defined by this document (see Section 8) have property names that are the same as the name of the RDAP object member that is the subject of the search: for example, the reverse search with the property name "fn" relies on the value of the "fn" member inside the jCard of an entity object./ New: / All of the reverse searches defined by this document (see Section 8) have property names that are the same as the name of the RDAP object member that is the subject of the search. For example, the reverse search with the property name "fn" relies on the value of the "fn" member inside the jCard of an entity object./ [ML] OK. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [Gen-art] Genart last call review of draft-ietf-regext-rdap-reverse-search-24
Hi Susan, thanks a lot for your review. Please find my comments inline. Il 21/08/2023 22:14, Susan Hares via Datatracker ha scritto: Reviewer: Susan Hares Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-regext-rdap-reverse-search-?? Reviewer: Susan Hares Review Date: 2023-08-21 IETF LC End Date: 2023-08-11 IESG Telechat date: 2023-08-24 Summary: The text is readable even for a novice in RDAP. I appreciated how sections 13 and 14 discussed the tension between the need for operational data and the need for the privacy of personal information. It is important that registry operators who use this technology to provide reverse RDAP provide clear communication to the following groups of people: a) the people registering this data, b) security personnel within the registry operator providing the data, c) any people allowed to access the data, and d) other registries that may import data from this registry. I find this text to be sufficient. I will please to see the security-DIR review found it ready to publish. Nits/editorial comments: Nits: Nit-#1: Section 1: It would be helpful to the naive reader to provide an IETF link for whois in section 1. [ML] OK. Looks better to move up the link to RFC 3912 to the sentence including "... standardized Whois capability ... ". Editorial comments: English textual comments to improve readability. #1 Section 1, paragraph 1 Old:/Since RDAP consequently permits a reverse search implementation complying with privacy protection principles, this objection is not well-founded./ New:/Since RDAP consequently permits a reverse search implementation complying with privacy protection principles, this first objection is not well-founded./ [ML] OK. #2 Section 1: paragraph 2 Old:/The other objection to the implementation of a reverse search capability has been connected with its impact on server processing./ New:/The second objection to the implementation of a reverse search capability has been connected with its impact on server processing./ [ML] OK. #3, Section 1: paragraph 2 Old: / However, the core RDAP specifications already define search queries, with similar processing requirements, so the distinction on which this objection is based is not clear./ New: /However, the core RDAP specifications already define search queries with similar processing requirements so the basis of this objection is based is not clear./ [ML] Do you mean "... so the basis of this objection is not clear" ? Section 3, paragraph 2 Old: /All of the reverse searches defined by this document (see Section 8) have property names that are the same as the name of the RDAP object member that is the subject of the search: for example, the reverse search with the property name "fn" relies on the value of the "fn" member inside the jCard of an entity object./ New: / All of the reverse searches defined by this document (see Section 8) have property names that are the same as the name of the RDAP object member that is the subject of the search. For example, the reverse search with the property name "fn" relies on the value of the "fn" member inside the jCard of an entity object./ [ML] OK. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [regext] Opsdir last call review of draft-ietf-regext-rdap-reverse-search-24
P search queries already exist. But looking at related RFCs I see examples where specific controls (rate limiting, response codes for too many queries, etc) are described. So I think the concern is clear, rather the text should state that controls can be implemented, or indeed SHOULD be, later in the document. [ML] The concern is about RDAP searches in general, not specifically about the reverse searches. In addition, the reverse search is not new in RDAP. RFC 9082 defines queries to search for domains starting for a detail of the associated name servers. This document just aims to describe a formal query model addressing every kind of reverse search based on the relationships between the RDAP objects. RFC 8977 and RFC 8982 already provide guidance to implementers on how to make searches more sustainable for both clients and servers but, obviously, RDAP providers can implement additional measures with the same purpose. That said, Section 10 already includes text recommending to use techniques speeding up the data retrieval and mitigating the risks of performance degradation. Hence, IMO, it already addresses your remark. Finally, related, I welcome the details of implementations in the draft, but I note they are ‘alpha’ state. I’m curious as to their potential progression, and what testing at any scale may have bene done. [ML] At .it, we have implemented only the reverse search based on domain-entity relationship and it's unaccessible to public users. Presently it's available to registrar users under the conditions explained in my first comment and we plan to make it available to authorities soon. ARIN and APNIC have described in draft-ietf-regext-rdap-rir-search <https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/> a potential usage of the reverse search in their own RDAP servers. Best, Mario Best wishes, Tim -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-24.txt
Just published version -24 that addresses the feedback from Andy and Scott as DEs. Best, Mario Messaggio Inoltrato Oggetto: New Version Notification for draft-ietf-regext-rdap-reverse-search-24.txt Data: Thu, 17 Aug 2023 06:46:06 -0700 Mittente: internet-dra...@ietf.org A: Mario Loffredo , Maurizio Martinelli A new version of I-D, draft-ietf-regext-rdap-reverse-search-24.txt has been successfully submitted by Mario Loffredo and posted to the IETF repository. Name: draft-ietf-regext-rdap-reverse-search Revision: 24 Title: Registration Data Access Protocol (RDAP) Reverse Search Document date: 2023-08-17 Group: regext Pages: 23 URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-24.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-reverse-search-24 Abstract: The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)
Il 17/08/2023 13:19, Andrew Newton ha scritto: On Thu, Aug 17, 2023 at 4:43 AM Mario Loffredo wrote: Hi Andy, could it work for you and Scott if I changed the text in Section 12.2.1 as in the following ? OLD Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. NEW Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. Likewise, they SHOULD NOT map a registered reverse search property to a response field with a meaning other than that of the response fields referenced by the mappings already registered for that property. In other words, all the mappings for a reverse search property MUST point to response fields with the same meaning. Could I offer a slight modification? Of course, no problem. I'll added it to the new version. Thanks, Mario NEW Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. Creators MAY register additional reverse search mappings for existing properties, but they SHOULD NOT map a registered reverse search property to a response field with a meaning other than that of the response fields referenced by the mappings already registered for that property. In other words, all the mappings for a reverse search property MUST point to response fields with the same meaning. -andy -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)
Il 17/08/2023 13:19, Andrew Newton ha scritto: On Thu, Aug 17, 2023 at 4:43 AM Mario Loffredo wrote: Hi Andy, could it work for you and Scott if I changed the text in Section 12.2.1 as in the following ? OLD Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. NEW Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. Likewise, they SHOULD NOT map a registered reverse search property to a response field with a meaning other than that of the response fields referenced by the mappings already registered for that property. In other words, all the mappings for a reverse search property MUST point to response fields with the same meaning. Could I offer a slight modification? Of course, no problem. I'll added it to the new version. Thanks, Mario NEW Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. Creators MAY register additional reverse search mappings for existing properties, but they SHOULD NOT map a registered reverse search property to a response field with a meaning other than that of the response fields referenced by the mappings already registered for that property. In other words, all the mappings for a reverse search property MUST point to response fields with the same meaning. -andy -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)
Hi Andy, could it work for you and Scott if I changed the text in Section 12.2.1 as in the following ? OLD Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. NEW Creators of either new RDAP reverse searches or new mappings for registered reverse searches SHOULD NOT replicate functionality already available by way of other documents referenced in these registries. Likewise, they SHOULD NOT map a registered reverse search property to a response field with a meaning other than that of the response fields referenced by the mappings already registered for that property. In other words, all the mappings for a reverse search property MUST point to response fields with the same meaning. Best, Mario Il 16/08/2023 17:17, Andrew Newton ha scritto: Thanks Mario. I understand the intent and had assumed that multiple mappings were allowed. While Scott and I understand, do we feel that future DE's might need better guidance? Is the term "collisions" clear enough for a future DE that may not have the benefit of having read this email thread? -andy On Mon, Aug 14, 2023 at 3:34 AM Mario Loffredo wrote: Hi Andy, please find my comments inline. Il 11/08/2023 14:16, Andrew Newton ha scritto: I wish I had asked this during the WG discussion, but I do have a question. Section 12.2.1 paragraph 3 states: "The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability. References are not limited only to RFCs and simple definitions could be described in the registries themselves." Does this mean that no duplicates in the RDAP Reverse Search Mapping (section 12.2.4) are allowed? [ML] What do you mean with "duplicates" ? Under the conditions of sections 12.2.3.1. and 12.2.4.1. about the uniqueness of the registries entries , duplicated entries are clearly not possible. Instead it's allowed that a single reverse property maps to more than one response fields. In this case one entry in the "Reverse Search" registry will split into more entries in the "Reverse Search Mapping" registry depending on the varipus values of the "Property Path" field. The classical example is the "fn" reverse search property that maps to multiple response fields based on the given contact format. But each of those response fields has the same meaning namely the contact full name. The term "collisions" is used in that sentence to refer to the case where the DEs receive two registration requests for the same reverse search property that maps to two response fields having different meaning. It's unliely to happen but we can't exclude it. If this is the case, that means a reverse search of "fn" will only apply to jCard and cannot be applied to JSContact or SimpleContact since the registration for "fn" is jCard specific. Is this intentional? [ML] As pointed out above, the "fn" reverse search property will also apply to other contact representations as the value of the "Property Path" field will be different according to the contact representation used. The name of the reverse search property is just a conventional name that doesn't need to exactly match that of the response field it maps to. For example, "fn" can map to the jCard "fn" as well as to the property representing the contact full name in any other contact representation. The same goes for "email". The name "fn" has been used for compatibility with the corresponding query parameter defined in RFC 9082 to search for entities. I see this in section 5: "Documents that deprecate or restructure RDAP responses such that a registered reverse search is no longer able to be used MUST either note that the relevant reverse search is no longer available (in the case of deprecation) or describe how to continue supporting the relevant search by adding another mapping for the reverse search property (in the case of restructuring)." It implies that duplicates are allowed, at least to me. [ML] See my previous comments. Mario -andy On Thu, Aug 10, 2023 at 6:41 PM David Dong via RT wrote: Dear Andy and Scott (cc: regext WG), As the designated experts for the RDAP Extensions registry, can you review the proposed registration in draft-ietf-regext-rdap-reverse-search-23 for us? Please see: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ The due date is August 24th. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/rdap-extensions/ Unless you ask us to wait for the other reviewer, we’ll act on t
Re: [regext] [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)
Hi Andy, please find my comments inline. Il 11/08/2023 14:16, Andrew Newton ha scritto: I wish I had asked this during the WG discussion, but I do have a question. Section 12.2.1 paragraph 3 states: "The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability. References are not limited only to RFCs and simple definitions could be described in the registries themselves." Does this mean that no duplicates in the RDAP Reverse Search Mapping (section 12.2.4) are allowed? [ML] What do you mean with "duplicates" ? Under the conditions of sections 12.2.3.1. and 12.2.4.1. about the uniqueness of the registries entries , duplicated entries are clearly not possible. Instead it's allowed that a single reverse property maps to more than one response fields. In this case one entry in the "Reverse Search" registry will split into more entries in the "Reverse Search Mapping" registry depending on the varipus values of the "Property Path" field. The classical example is the "fn" reverse search property that maps to multiple response fields based on the given contact format. But each of those response fields has the same meaning namely the contact full name. The term "collisions" is used in that sentence to refer to the case where the DEs receive two registration requests for the same reverse search property that maps to two response fields having different meaning. It's unliely to happen but we can't exclude it. If this is the case, that means a reverse search of "fn" will only apply to jCard and cannot be applied to JSContact or SimpleContact since the registration for "fn" is jCard specific. Is this intentional? [ML] As pointed out above, the "fn" reverse search property will also apply to other contact representations as the value of the "Property Path" field will be different according to the contact representation used. The name of the reverse search property is just a conventional name that doesn't need to exactly match that of the response field it maps to. For example, "fn" can map to the jCard "fn" as well as to the property representing the contact full name in any other contact representation. The same goes for "email". The name "fn" has been used for compatibility with the corresponding query parameter defined in RFC 9082 to search for entities. I see this in section 5: "Documents that deprecate or restructure RDAP responses such that a registered reverse search is no longer able to be used MUST either note that the relevant reverse search is no longer available (in the case of deprecation) or describe how to continue supporting the relevant search by adding another mapping for the reverse search property (in the case of restructuring)." It implies that duplicates are allowed, at least to me. [ML] See my previous comments. Mario -andy On Thu, Aug 10, 2023 at 6:41 PM David Dong via RT wrote: Dear Andy and Scott (cc: regext WG), As the designated experts for the RDAP Extensions registry, can you review the proposed registration in draft-ietf-regext-rdap-reverse-search-23 for us? Please see: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ The due date is August 24th. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/rdap-extensions/ Unless you ask us to wait for the other reviewer, we’ll act on the first response we receive. With thanks, David Dong IANA Services Sr. Specialist ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Secdir last call review of draft-ietf-regext-rdap-reverse-search-23
Hi Tero, thanks a lot for your review. Please find my comments below. Il 08/08/2023 21:45, Tero Kivinen via Datatracker ha scritto: Reviewer: Tero Kivinen Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the reverse search method for RDAP protocol. It does include implementation considerations, privacy considerations in addition security considerations, which do list number of issues that the implementations need to solve. Including limiting number of resources returned, protecting Personally Identifiable Information, and methods of doing authentication. It does require HTTPS because of the privacy concerns, but authentication and authorization is only SHOULD: In general, given the sensitivity of this functionality, it SHOULD be accessible to authorized users only, and for specific use cases only. This SHOULD does not list reason when it would be ok to provide this information without authorization. I would assume one such use case would be when there is no PII or sensitive information in the database... [ML] Yes, that is the main case where authorization couldn't be needed. Since the document defines a generic reverse search model based on the relationships between RDAP objects, the reverse search property used in the query couldn't correspond to PII or sensitive information. RFC 9082 already defines two reverse-like searches not based on PII (i.e. nsLdhName and nsIp) to find all the domains associated to the nameservers matching the search pattern. However, I don't have a legal background hence I can't exclude reverse search implementations based on entity details which wouldn't require the requestor to be authorized first while being still compliant with laws or regulations that restrict the use of personal data. Based in my experience, the two things are incompatible with each other. Best, Mario -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Artart last call review of draft-ietf-regext-rdap-reverse-search-23
Hi Scott, thanks a loto for your review. I'll change the text as you suggested. Best, Mario Il 02/08/2023 14:43, Scott Hollenbeck via Datatracker ha scritto: Reviewer: Scott Hollenbeck Review result: Ready with Nits I reviewed this document as part of the Applications and Real-Time (ART) Area Review Team's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the ART Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. I found only one small issue that should be addressed: Section 12.2.1 (Creation of the RDAP Reverse Search Registries) states that "These registries follow the Specification Required process as defined in Section 4.5 of [RFC8126]". It further states that "The designated expert should prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability". The issue is that no designated expert is involved when the Specification Required process is used to populate a registry. The text could be rewritten like this: "The specification should be written to prevent collisions and confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability" -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-23.txt
Hi Murray, hope that all of your remarks have been addressed and you like the way I have rearranged the initial content of IANA registries to make it more compact and readable. Best, Mario Messaggio Inoltrato Oggetto: New Version Notification for draft-ietf-regext-rdap-reverse-search-23.txt Data: Fri, 28 Jul 2023 01:09:12 -0700 Mittente: internet-dra...@ietf.org A: Mario Loffredo , Maurizio Martinelli A new version of I-D, draft-ietf-regext-rdap-reverse-search-23.txt has been successfully submitted by Mario Loffredo and posted to the IETF repository. Name: draft-ietf-regext-rdap-reverse-search Revision: 23 Title: Registration Data Access Protocol (RDAP) Reverse Search Document date: 2023-07-28 Group: regext Pages: 22 URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-23.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-reverse-search-23 Abstract: The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Publication has been requested for draft-ietf-regext-rdap-reverse-search-22
Hi Murray, Il 28/07/2023 02:43, Murray S. Kucherawy ha scritto: On Wed, Jul 26, 2023 at 4:07 AM Mario Loffredo wrote: * Section 3 should probably specify what should happen if the JSONpath refers to an attribute/value that's not present in the object it's referencing. [ML] The JSONPath expressions related to reverse search properties are provided by servers and have been previously registered with IANA, hence they have been checked by Designated Experts. It's very unlikely they are wrong. Can't imagine how clients can operate when servers provide wrong information. I mean, servers can return an error code when clients include wrong or unsupported reverse search properties in thei requests, but servers are always expected to provide correct data. It just feels strange to presume you will always have valid input and never discuss error condition handling. I'm still learning about JSONpath (it's also in "AD Evaluation") so maybe this is a teachable moment for me, but it seems like there's a presumption that a query will always be run against a value that will resolve; is that the case here too? Maybe we should say that if so. [ML] Probably I didn't make myself clear or I still don't catch your remark. The JSONPath expressions are provided by servers to help clients in linking the available reverse search properties to the reponse fields. Client can only use the reverse search properties in their queries. The invalid use of both reverse search poperties and predicates by clients results in servers returning an error as defined in Section 7: Now that I'm done with my review of JSONpath and got that WG to explain this to me, you can ignore my suggestion. JSONpath, if you run it on a value that doesn't include what you're trying to "path" to, just returns an empty result with no error. Since you're building on top of that, that's also what you get. Therefore, as long as your specification can handle an empty JSONpath result *or* you say explicitly that your specification is based on the assumption that that'll never happen, then there's not much you need to say, and we're good here. IMO, the document already covers those cases. Hence, no further change is needed about this matter. Do you agree ? Yup. Let's go. Is the current version ready or do you need one more after this review? Yes, it is. I'll publish it today. Best, Mario -MSK ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Publication has been requested for draft-ietf-regext-rdap-reverse-search-22
Hi Murray, thanks for your reply. Please find my responses inline. Il 25/07/2023 22:49, Murray S. Kucherawy ha scritto: On Tue, Jul 11, 2023 at 8:44 AM Mario Loffredo wrote: * In Sections 12.2.3.2 and 12.2.4.2, the individual entries are run together into one big blob. Could we get blank lines between them, or maybe put each in its own subsection if necessary? Or make it a table? [ML] I know that the layout is redundant and not compact at all but it's the only one making the JSONPath expressions quite readable. I can move the fileds assuming always the same value (e.g. "Related Resource Type", "Registrant Name" and "Registrant Information") at the beginning so that each group of properties related to an entry in the IANA registry gets shorter. Does it work for you ? Looks like you could put each of the four registrations in its own subsection to nail this down. But what's weird is that if I view it here: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-22 ...it's all mashed together, but when I view it here: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-22.html ...it looks fine. Let's just leave it for now (unless you like the subsections idea) and ask the RFC Editor to help with formatting. It may become an issue earlier if IANA finds it confusing. [ML] Hope I made it more readable. Let's how it will be rendered. I checked the layout in TXT, HTML and PDF and looks good to me. * In Section 13, we have a "REQUIRED" followed by some non-specific advice about what to implement. This doesn't seem like a good use of BCP 14 key words. Can we say it some other way? [ML] Would it be better to use "SHOULD" instead of "are REQUIRED to" ? I would change "are REQUIRED" to "need". The problem I have is that saying "you are REQUIRED to assure privacy" doesn't tell the implementer exactly what needs to happen to interoperate or assure privacy, so being able to specify what it will take to comply isn't possible. It's like the difference between saying "you MUST make sure your data are secured somehow" versus "you MUST use TLS 1.3"; it's easy to prove compliance with one of those, but not the other. [ML] Agreed. * Section 3 should probably specify what should happen if the JSONpath refers to an attribute/value that's not present in the object it's referencing. [ML] The JSONPath expressions related to reverse search properties are provided by servers and have been previously registered with IANA, hence they have been checked by Designated Experts. It's very unlikely they are wrong. Can't imagine how clients can operate when servers provide wrong information. I mean, servers can return an error code when clients include wrong or unsupported reverse search properties in thei requests, but servers are always expected to provide correct data. It just feels strange to presume you will always have valid input and never discuss error condition handling. I'm still learning about JSONpath (it's also in "AD Evaluation") so maybe this is a teachable moment for me, but it seems like there's a presumption that a query will always be run against a value that will resolve; is that the case here too? Maybe we should say that if so. [ML] Probably I didn't make myself clear or I still don't catch your remark. The JSONPath expressions are provided by servers to help clients in linking the available reverse search properties to the reponse fields. Client can only use the reverse search properties in their queries. The invalid use of both reverse search poperties and predicates by clients results in servers returning an error as defined in Section 7: * * *Servers MUST return an HTTP 501 (Not Implemented) **[RFC9110 <https://author-tools.ietf.org/api/export/be29d181-e21a-48ce-afdb-d5731c79c81c/draft-ietf-regext-rdap-reverse-search-23.html#RFC9110>]**response to inform clients of unsupported reverse searches.* *Based on their policy, servers MAY restrict how predicates are used to make a valid search condition, by returning a 400 (Bad Request) response when a problematic request is received.* Obviously, it can happen that a server returns an either wrong or unmatched JSONPath expression in the reverse_search_properties_mapping member. In this case, think there are two options for the client: 1) The JSONPath expression is wrong but the related reverse search property works (e.g. the propertyPath value for the "email" reverse search property is "$.entities[*].vcardArray[1][?(@[0]=='email')][*2*]" instead of "$.entities[*].vcardArray[1][?(@[0]=='email')][*3*]"). The server will return a valid response. If a client will discover the mistake in JSONPath e
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt
Il 17/07/2023 13:25, Andrew Newton ha scritto: Hi Mario, my responses are inline. On Mon, Jul 17, 2023 at 3:42 AM Mario Loffredo wrote: [ML] 1) In addition to Pawel's feedback, it seems to me that, unless you leverage a REST plugin, you are unable to use this extension through a web browser. The browser Javascript Fetch API supports setting Accept headers. There is no need for a specific plugin. I meant just a raw web browser not a browser-based client. Mario 2) Does this document update RFC 9083 ? RFC 9083 states that type is an OPTIONAL member of the link data structure while this document states that "application/rdap+json media type is RECOMMENDED when the URI references RDAP resources" I don't think so. This RECOMMENDED is only for rdap-x. As an aside note of the considerations at point 1, would like to know the current WG's opinion about how relevant is making an RDAP server easily accessible by a web browser. If I remember well, it has been vey relevant in the past. But this document goes in the opposite direction. Hence I'm not so sure it will keep on being relevant in the future. All of the RIRs and ICANN have browser-based RDAP clients. Plus there are a handful of independent browser-based clients. So they are very relevant. I even wrote one a number of years ago using jQuery. Here is where it sets an explicit Accept header media type: https://github.com/anewton1998/rdap_webspa/blob/8e49ee8fae56dd2cbdd3fd575d38e9f8996b6dcf/src/logic.js#L416 But there is no need to draw a distinction between browser-based clients and non-browser clients in this regard. Both should work. -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-x-media-type-00.txt
Hi Andy, please find my comments below. Il 12/07/2023 15:35, Andrew Newton ha scritto: Thanks for the review Pawel. My response is in-line: On Wed, Jul 12, 2023 at 2:41 AM Pawel Kowalik wrote: Hi Andy, Thanks for putting down this draft. A method for the client to signal supported or wanted extensions is really needed. A remark to the Section 3: I think all cases should be covered by this section. Currently I'm missing, the case when the server would support more extensions than requested/understood by the client. I think it would be good to make a recommendation for the server implementation what is the desired behavior in such case. My suggestion is the server SHOULD respond with no additional extensions as far as the server capable of doing so (e.g. can render dynamic responses). It may be relevant for the cases where the extensions define not only JSON structures, which in general should not be an issue for the client receiving an unsupported extension, but also define a response profile which not necessarily have to be compatible with each other. Yes, I think we should cover this scenario. Thanks for pointing it out. And I agree with your suggested behavior. [ML] 1) In addition to Pawel's feedback, it seems to me that, unless you leverage a REST plugin, you are unable to use this extension through a web browser. Neither setting the "type" property in the links could be useful. In particular, with regard to the farv1 extension, the REST plugin couldn't be used either because the user is redirected to the OP authentication form at login. Therefore, IMO a text is needed to clarify that this extension is primarily intended for RDAP clients. 2) Does this document update RFC 9083 ? RFC 9083 states that type is an OPTIONAL member of the link data structure while this document states that "application/rdap+json media type is RECOMMENDED when the URI references RDAP resources" As an aside note of the considerations at point 1, would like to know the current WG's opinion about how relevant is making an RDAP server easily accessible by a web browser. If I remember well, it has been vey relevant in the past. But this document goes in the opposite direction. Hence I'm not so sure it will keep on being relevant in the future. Best, Mario [snip] ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Publication has been requested for draft-ietf-regext-rdap-reverse-search-22
Hi Murray, thanks a lot for your review and feedback. Please find my comments inline. Il 10/07/2023 05:22, Murray S. Kucherawy ha scritto: On Mon, May 15, 2023 at 12:06 PM Antoin Verschuren via Datatracker wrote: Antoin Verschuren has requested publication of draft-ietf-regext-rdap-reverse-search-22 as Proposed Standard on behalf of the REGEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ Sorry for the delay getting to this. I think it's in generally good shape. I've got only a few comments before we can Last Call it: * In Sections 12.2.3.2 and 12.2.4.2, the individual entries are run together into one big blob. Could we get blank lines between them, or maybe put each in its own subsection if necessary? Or make it a table? [ML] I know that the layout is redundant and not compact at all but it's the only one making the JSONPath expressions quite readable. I can move the fileds assuming always the same value (e.g. "Related Resource Type", "Registrant Name" and "Registrant Information") at the beginning so that each group of properties related to an entry in the IANA registry gets shorter. Does it work for you ? * In Section 13, we have a "REQUIRED" followed by some non-specific advice about what to implement. This doesn't seem like a good use of BCP 14 key words. Can we say it some other way? [ML] Would it be better to use "SHOULD" instead of "are REQUIRED to" ? * Thanks for including Section 11. * Section 3 should probably specify what should happen if the JSONpath refers to an attribute/value that's not present in the object it's referencing. [ML] The JSONPath expressions related to reverse search properties are provided by servers and have been previously registered with IANA, hence they have been checked by Designated Experts. It's very unlikely they are wrong. Can't imagine how clients can operate when servers provide wrong information. I mean, servers can return an error code when clients include wrong or unsupported reverse search properties in thei requests, but servers are always expected to provide correct data. Best, Mario -MSK ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-00.txt
Il 06/07/2023 16:42, Andrew Newton ha scritto: Honestly, I don't think jCard structured postal addresses are compatible with many westernized countries as well. That's why SimpleContact only models the locality and less specific information. PIDF-LO provides an excellent example of the difficulty in modeling sub-locality information. [ML] If the JSContact representation for postal addresses is not enough, one can simply register a new value for the kind property of the AddressComponent. The data structure remains the same but you are able to specify additional address components without loosing information. But I imagine that your objection is that representing a postal address as an extensible array of components is too much work for the clients and 99% of RDAP addresses don't need additional components. Best, Mario -andy On Wed, Jul 5, 2023 at 7:20 PM George Michaelson wrote: In fairness to Mario, I should own up to speaking about non-western postal address issues in the past on-list and at the microphone, and as an RIR person. I think Mario would have been entitled to assume that meant we expected to use them or did use them. That I am not involved in the adoption or use of RDAP any more, means I can't comment to their relevance. But, in times past I did advocate a view this was important. (purely as a 'point of information' to this concern) -George ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-00.txt
Hi Andy, please find me responses inline. Il 06/07/2023 16:37, Andrew Newton ha scritto: Response in-line: On Thu, Jul 6, 2023 at 2:08 AM Mario Loffredo wrote: For example, if you take a look at the "CENTR white paper on data accuracy", you will realize that the are registries storing the date of birth of registrants as individuals. Data accuracy is a relevant topic for the European registries. Registration data should be as detailed as possible to permit the execution of consistency checks and identify fake data. Is this the whitepaper? https://www.centr.org/library/library/download/10478/7435/41.html Are any CENTR registries or registrars publishing that information? I am not a lawyer, but that would seem to run counter to GDPR. The whitepaper also mentions the National ID of individuals. Are they publishing that as well? I ask because that couldn't happen in the United States, and we have some of the worst privacy laws in the world. If the wg wants to add them in, I suggest doing so under a proviso that the information MUST be strictly published for non-public use. [ML] If that information is collected, it doesn't necessarily mean that it is publicly available. It can simply be accessed by any allowed user. What should be the usefulness of rdap-openid if RDAP responses couldn't be provided based on user profiles ? [ML] They are used (see for example https://rdap.arin.net/registry/ip/199.0.0.0) We left them in the draft but want the WG to guide here. Good catch. I guess that answers that question. [ML] The point is that the property name "individualNames" is misleading: do you mean that a contact can have more names or do you mean that a contact has one only name and can have some translations ? It's the latter. We can add some clarifying text. The plural JSON names are done purposefully for things that are arrays. But that's just a style issue. [ML] I guessed it was the latter. IMHO, the information and its language-dependent version are two distinct things. In this case, there is one only name in the native (default) language and many translations of it in different languages. a) some registries use the LANG property to set the default language That's addressed in section 2: "There are two common, optional JSON members of these child members: "lang" and "masked".The JSON member "lang" is the same as that defined by RDAP..." [ML] The LANG property in RFC6350 is the default contact language, hence it is different from the "lang" attribute as defined in section 4.4. of RFC 9083. Otherwise, don't see how it is used in some jCard examples of RFC 9083. The text indicates that it is the same format, not the same purpose. We can clarify that and add some more examples to make it clearer. Think that specifying the default language in one place would be better than repeating it in every object where it makes sense. Why? That seems to be more work for the client. [ML] We have different opinions about what it means "doing more work". For example, I believe that having a apecific handling of language-dependent alternatives for each object takes more work than implementing a method that can process every localizations including those related to extensions. b) some registries use the PREF parameter of TEL and EMAIL properties (e.g., if I remeber well, APNIC represents the preference information in email addresses) Also addressed in section 2: "Most of the child members are arrays allowing the expression of multiple variants of the same information. The order in which items appear in these arrays denotes preference order for the variants." [ML] This preference information is not the same as that defined by RFC 6350 since it assumes that every collection is sorted by preference. On the contrary, RFC 6350 admits cases where there is no preference. Hence, RFC 6350 (and JSContact) is more flexible here. For example, do you mean that in the voicePhones example the preferred phone number to be used is the first one ? What's the practical difference to a client? A client would use the same display logic for implied preference order and no preference order. We can add explicit preferences, but it seems unnecessary and puts more work on the client. [ML] If the logic was to search for the preferred item if any, the response would be different. For example, in the case of a company offering multiple phone numbers in order to be contacted, the effect on the distribution of the phone calls is different if there is a preferred number or no preferred number. Anyway, if you think that using the array order is an unambiguous way to represent preference or not, go that way. c) some registries use the TEL-TYPE parameter (e.g. to represent work phone numbers) Those would be "voicePhones" in SimpleContact. See Section 2.5. [ML] Here again the RFC6350 (and JSContact
[regext] Fwd: Confirm submission of I-D draft-ietf-regext-rdap-jscontact
This is for compliance with new JSContact spec. Changes are listed in the change log section. Best, Mario Messaggio Inoltrato Oggetto:Confirm submission of I-D draft-ietf-regext-rdap-jscontact Data: Thu, 06 Jul 2023 02:26:34 -0700 Mittente: IETF I-D Submission Tool A: Gavin Brown , Mario Loffredo Hi, The IETF datatracker Internet-Draft submission service has received your Internet-Draft draft-ietf-regext-rdap-jscontact-17, and requires a confirmation step in order to be able to complete the posting of the Internet-Draft. Please follow this link to the page where you can confirm the posting: https://datatracker.ietf.org/submit/status/134795/confirm/877f566f9ed01b0552f4b70b21283946/ Best regards, The IETF Secretariat through the Internet-Draft submission service ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-00.txt
Hi Jasdip, please find my comments below. Il 05/07/2023 23:35, Jasdip Singh ha scritto: On 7/5/23, 3:44 PM, "regext on behalf of Andrew Newton" mailto:regext-boun...@ietf.org> on behalf of a...@hxr.us <mailto:a...@hxr.us>> wrote: 5) I'm very curious to know the WG reaction about the use of "noJCard" extension. AFAIK, providing an alternative represention along with jCard in an RDAP response has not been considered an issue so far even in case of handling large amounts of data. Most of us (not me) have considered too complex for both clients and servers to imlement the negotiation of the contact representation to be returned in the response. In addition, in this case, the negotiation is made through two extension identifiers while in rdap-jscontact setting the jscard parameter to 1/true means that jCard is not returned. For most lookups, returning both will not matter much. However, for searches yielding many more than one result it could be a definite bandwidth savings. The implementation would most likely be up to server policy on the server side. [JS] Mario, sorry if I sound a bit biased here but IMO using the "noJCard" extension along with the RDAP-X based content negotiation looks like a rather neat idea whether used for Simple Contact or JSContact. It avoids the query parameter-based issues when negotiating content, as explained in the RDAP-X draft. [ML] The objection was not on how negotiation should occur but in that it was easier for both RDAP servers and clients to have jCard and JSContact together in the same respose. I'm happy to note that the wind is changing and now the focus is on the issues connected with the response payload as I have always outlined (and demonstrated through numbers). As a result, (I would say magically) handling the combination of some extension identifiers has become less complex for both clients and servers than using a single parameter. Best, Mario Jasdip -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-00.txt
Hi Andy, please find my comments below. I added some examples of RDAP queries returning responses including features that in my opinion are not fully matched by this specification. It took very short time to me to discover those responses and I did it by using only the information included in the bootstrap registries. As a result, I can say that they are not corner cases and there might be further jCard features that have not been considered. For example, if you take a look at the "CENTR white paper on data accuracy", you will realize that the are registries storing the date of birth of registrants as individuals. Data accuracy is a relevant topic for the European registries. Registration data should be as detailed as possible to permit the execution of consistency checks and identify fake data. Il 05/07/2023 21:43, Andrew Newton ha scritto: Mario, Thanks for looking at it. My comments are in-line: On Wed, Jul 5, 2023 at 2:42 PM Mario Loffredo wrote: Hi Andy, thanks for this document. I can finally compare it with JSContact and provide some feedback: 1) First, I'm happy to note that, with reference to the first draft proposal included in https://mailarchive.ietf.org/arch/msg/regext/56Nk70dpoxFOdlK2rw_QSiPlg9Q/, some arrays of values have been turned into either objects or arrays of objects and further information has been modeled. This is because SimpleContact has become "more complex" to support additional features not considered initially. In some cases, this specification is even "more complex" than JSContact (e.g. in JSContact the name information is represented through a single object instead of a collection). If I may, by using your words, I would say that SimpleContact is making the same mistake as JSContact about the use of arrays and objects. The JSON style issue aside, we did note that structured names do not appear to be used in RDAP. See the references in Section 1 of the draft. [ML] They are used (see for example https://rdap.arin.net/registry/ip/199.0.0.0) We left them in the draft but want the WG to guide here. [ML] The point is that the property name "individualNames" is misleading: do you mean that a contact can have more names or do you mean that a contact has one only name and can have some translations ? 2) It seems to me that this specification doesn't ensure the full backward compatibility with all of the jCard features currently used in RDAP. Here in the following some of them: a) some registries use the LANG property to set the default language That's addressed in section 2: "There are two common, optional JSON members of these child members: "lang" and "masked".The JSON member "lang" is the same as that defined by RDAP..." [ML] The LANG property in RFC6350 is the default contact language, hence it is different from the "lang" attribute as defined in section 4.4. of RFC 9083. Otherwise, don't see how it is used in some jCard examples of RFC 9083. Think that specifying the default language in one place would be better than repeating it in every object where it makes sense. b) some registries use the PREF parameter of TEL and EMAIL properties (e.g., if I remeber well, APNIC represents the preference information in email addresses) Also addressed in section 2: "Most of the child members are arrays allowing the expression of multiple variants of the same information. The order in which items appear in these arrays denotes preference order for the variants." [ML] This preference information is not the same as that defined by RFC 6350 since it assumes that every collection is sorted by preference. On the contrary, RFC 6350 admits cases where there is no preference. Hence, RFC 6350 (and JSContact) is more flexible here. For example, do you mean that in the voicePhones example the preferred phone number to be used is the first one ? c) some registries use the TEL-TYPE parameter (e.g. to represent work phone numbers) Those would be "voicePhones" in SimpleContact. See Section 2.5. [ML] Here again the RFC6350 (and JSContact) is more flexible since you are allowed to specify if a phone number is private or is used for work (see https://rdap.cctld.kg/domain/nic.kg and https://flexireg.net/moscow/rdap/domain/nic.moscow) d) some further jCard features included in RFC 9083 examples don't find counterparts in this specification (e.g. KEY, TZ, TITLE properties). Do you plan to match such features ? If people use them, then yes. Are they used by DNRs or RIRs today? [ML] I see only two alternatives: 1) The example in RFC 9083 is impractical then it should be corrected 2) The example in RFC 9083 is practical then a contact representation in RDAP should consider those features Another answer could be: do you think that it might be used in the future ? Honestly, I wouldn't base my data model solely on the info
Re: [regext] Fwd: New Version Notification for draft-newton-regext-rdap-simple-contact-00.txt
JSContact. The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. Mario Loffredo Senior Technologist 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-rdap-opened-22
+1 Mario Il 26/06/2023 16:02, James Galvin ha scritto: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 10 July 2023. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Zaid AlBanna. Thanks, Jim and Antoin REGEXT WG Co-Chairs ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] status draft-ietf-regext-rdap-redacted-12
Hi Andy, please find my comment below. Il 26/06/2023 16:38, Andrew Newton ha scritto: On Mon, Jun 26, 2023 at 9:49 AM James Galvin wrote: 2. Andy Newton needs to confirm on the list that all of his concerns have been addressed. Tom Harrison has already indicated that his concerns have been addressed. My apologies. I confirm my concerns have been addressed. The Chairs would also like to note that given the new discussion regarding jCard vs jsContact vs SimpleContact, that we will be delaying the actual submission of this document to the IESG until that discussion resolves. It seems prudent to make sure there is no impact to the “redacted” document as a result of the format discussion before we submit it to the IESG. I appreciate the prudence, and practically it may not matter if submission to the IESG is delayed given the dependency on JSONPath and IESG workload. That said, I do not believe this is necessary. Let me explain. Much of the complexity in the RDAP redaction spec has to do with getting around weird things in jCard, but as Marc has pointed out, jCard will be with us for the foreseeable future. Though I strongly suspect redaction will be easier with a theoretical SimpleContact, it could be quite some time before we know that. And the RDAP redaction spec covers more than contact data, so it is useful outside of the contact data discussions. The complications with redaction with regard to JSContact center around client processing of JSContact patch objects before, after or during client processing of the redaction directives. This is something the JSContact drafts could specify without need to modify the RDAP redaction, IMHO. I believe the UID issue has been resolved. Finally, JSContact may take some time to get to the publication point considering its dependency. That's my opinion. Maybe others see it differently. [ML] It's very hard for me to compare something existing and already implemented with something else I haven't yet seen. With regard to redacting a patch object, can you please provide me with some examples showing that redacting a patch object would need additional redaction methods not yet defined? Best, Mario -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Thoughts on the fundamental premise of JSContact
Hi Jasdip, Il 12/06/2023 22:24, Jasdip Singh ha scritto: Hello Mario, After reviewing the PatchObject data type [1] in JSContact, one question: How would the JSON serialization/deserialization work for a JSONPointer as a key (read: member name) in a PatchObject, given a programming language like Java does not allow a forward slash ( '/' ) in a variable name, AFAIK? It depends on how you deserialize the JSON content. A suggestion about how to implement the PatchObject in Java can be derived from its definition in JSContact: A PatchObject is of type String[*], and represents an unordered set of patches on a JSON object. Each key is a path represented in a subset of JSON pointer format [RFC6901]. Terms such as "unordered se" and "key" may suggest that the use of a Java Map can be the way to go to implemet PatchObject. After all, since you can localize every JSContact value no matter if its type is primitive, an object or an array and if the property to localize is a standard property or an extension, it would be inefficient to deserialize a PatchObject in an object whose members are fixed in adavance. In jscontact-tools, the "localizations" property is defined as in the following: Map> localizations; where JsonNode is the base class for all JSON nodes in jackson library. Serialization/deserialization takes place straightforwardly without customizations. FYI, you can find some examples of localizations handling by jscontact-tools at https://github.com/consiglionazionaledellericerche/jscontact-tools/blob/master/src/test/java/it/cnr/iit/jscontact/tools/test/localizations/LocalizationsTest.java . Hope it could be helpful. Yesterday I talked with Robert Stepanek and we agreed the PatchObject is more difficult to formally describe than to implement ;-) Best, Mario Jasdip [1]https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-11.html#name-patchobject On 6/9/23, 11:41 AM, "Andrew Newton" mailto:a...@hxr.us>> wrote: ... TBH, it was the JSContact patchobject that made me re-examine this space. I don't know the requirements for CalExt, but the necessity to implement a JSON patching framework to parse postal addresses seems to me to be beyond what is reasonable for RDAP. James has also pointed out several times that the JSContact UID may not be a good fit for RDAP. ... -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Thoughts on the fundamental premise of JSContact
Hi Andy, please find my comments below. Il 09/06/2023 17:41, Andrew Newton ha scritto: On Fri, Jun 9, 2023 at 10:03 AM Jasdip Singh wrote: Hello Mario, Your answer made my day! :) I'm still LOL about your "it wouldn't be short-sighted but completely blind" point. Yah, good to think this through before we as a WG take the next step. I recall one of the laws of simplicity [1]: law 9 which says that some things can never be made simple. May be, JSContact falls into that category. Trusting that the CalExt WG thought through about not unnecessarily introducing implementation complexity for JSContact. Regards, Jasdip [1] http://lawsofsimplicity.com/ TBH, it was the JSContact patchobject that made me re-examine this space. I don't know the requirements for CalExt, but the necessity to implement a JSON patching framework to parse postal addresses seems to me to be beyond what is reasonable for RDAP. [ML] CalExt adopted the same approach in designing JSCalendar. Anyway, the reason supporting the use of patchObject is simple: it is a more reusable and extensible approach than replicating in many objects the information needed to build language-dependent alternatives. vCard makes use of the LANGUAGE and ALTID parameters to build language-dependent alternatives. The two parameters are jointly allowed for about ten properties. In designing JSContact, instead of replicating that information in each of the ten JSContact counterparts of those vCard properties, we opted for defining a single point in the spec containing all the localizations. So doing, language based alternatives of a contact can always be built in the same way. This a big vantage especially for client applications which can provide a better user experience by enabling the language selection. For example, suppose you have a contact card whose default language is Japanese but an English version is provided as well. If you want to display the Japanese version, you just need to ignore the localizations. If you want do display the English vertsion, take the contact card, apply the patches (no matter if you are patching a standard property or an extension), display the resulting contact card. To be noted that extensions which can be localized don't need to include information to build language-dependent alternatives. On server side, you need to put the localized object and the corresponding localization in two different places but the steps to be done are, even in this case, always the same: construct the default language version of an object, put it into the right place of the card, construct the localization and put it as a generic object into the localizations map. On both sides, you need to know JSONPointer concepts and leverage the capabilities of a JSONPointer library. The implementation in jscontact-tools took to me very short time and frankly I'm not a great Java programmer. Hope now it's more clear why we have used PatchObject. Finally, consider that CalExt members usually join other forums like CalConnect where people are highly experienced with iCalendar and vCard. With regard to RDAP, honestlty can't evaluate the average number of contact properties that might be provided in other languages but the example in Fig.15 of RFC 9083 includes 7 properties that could be potentially localized: fn, n, org, title, role and two adr intances (one structured and one unstructured). If we consider the contact information defined by RFC 5733, the minimal set of properties that can be localized includes: fn, org and adr. James has also pointed out several times that the JSContact UID may not be a good fit for RDAP. [ML] JSContact uid takes the same role as jCard fn. Both of them are required. Depending on which format a server uses to represent JSContact uid, it can be redacted by either the replacementValue or the emptyValue method while jCard fn can be redacted only by emptyValue method. Therefore, after the discussion we have had, don't see why it could be an issue. Neither it looked an issue for you, if I remember well. On 6/9/23, 5:02 AM, "Mario Loffredo" mailto:mario.loffr...@iit.cnr.it>> wrote: Hi Jasdip, Il 08/06/2023 15:39, Jasdip Singh ha scritto: True, we could define an entity object class that serves the DNR and RIR purposes with a simpler JSON, just like we chose to define domain, IP network, and autonomous system number object classes that are specific to these registries' business. However, before abandoning the JSContact effort, one question to ask would be: Would it be short-sighted in precluding future user cases for entities in other registries (say, RDAP use for space related registration data)? Jasdip This is a good question to ask? What if a space registry needs to use RDAP? Let's say they need star-dates, celestial orbital planes, and jump-gate coordinates. Does JSContact currently support star-dates, celestial orb
Re: [regext] Thoughts on the fundamental premise of JSContact
Hi Jasdip, happy to have made your day. Unfortunately the rules of .it firewall forbid the access to that web page :-( The leading principle in JSContact design has always been to make it as comprehensive and extensible as possible. Maybe this may have resulted in more complexity now but I'm sure it will be balanced by more usefulness in the future. Robert and I are not masochist, we don't enjoy making complex things that would be easy otherwise. Things are inherently complex, escpecially if we consider that JSContact (like jCard) aims to be a generic contact representation that might be used in a variety of contexts. With regard to the RDAP contacts, are we really sure that, after matching all the requirements, the attempt of defining a simpler contact wouldn't end with a specification as complex as JSContact (with regard to the subset of JSContact mostly used in RDAP) ? Personally, I don't see a remarkable gap. Best, Mario Il 09/06/2023 16:03, Jasdip Singh ha scritto: Hello Mario, Your answer made my day! :) I'm still LOL about your "it wouldn't be short-sighted but completely blind" point. Yah, good to think this through before we as a WG take the next step. I recall one of the laws of simplicity [1]: law 9 which says that some things can never be made simple. May be, JSContact falls into that category. Trusting that the CalExt WG thought through about not unnecessarily introducing implementation complexity for JSContact. Regards, Jasdip [1] http://lawsofsimplicity.com/ On 6/9/23, 5:02 AM, "Mario Loffredo" mailto:mario.loffr...@iit.cnr.it>> wrote: Hi Jasdip, Il 08/06/2023 15:39, Jasdip Singh ha scritto: True, we could define an entity object class that serves the DNR and RIR purposes with a simpler JSON, just like we chose to define domain, IP network, and autonomous system number object classes that are specific to these registries' business. However, before abandoning the JSContact effort, one question to ask would be: Would it be short-sighted in precluding future user cases for entities in other registries (say, RDAP use for space related registration data)? Jasdip [ML] Would like to answer your question trying at the same time to recap the reasons why 3 years ago we didn't bring on Gavin's proposal about "a straight mapping of RFC5733 contact objects into JSON". I remember that at ROW 2019 George Michaelson from APNIC gave a presentation (https://regiops.net/wp-content/uploads/2019/05/ROW8-RDAPPanel-In-defence-of-jCard%E2%80%99s-goals-George-Michaelson.pdf <https://regiops.net/wp-content/uploads/2019/05/ROW8-RDAPPanel-In-defence-of-jCard%E2%80%99s-goals-George-Michaelson.pdf>) about which requirements a contact representation aiming to replace jCard was supposed to meet according to his experience. In that circumstance, it was clear to everyone that the EPP contact representation was pretty unfit to handle non-western registry data in general. Think that hopefully all of those requirements are matched by JSContact (e.g. we have recently updated the spec to better model non-western addresses but the work is still ongoing). Tom and George, can you please say your word on this matter ? Definitively, I believe that embracing the proposal of a contact data format based on RFC 5733 would be a huge step backwards in facing this problem. Jasdip, answering your question, I would say that it wouldn't be short-sighted but completely blind :-) Best, Mario On 6/8/23, 8:52 AM, "regext on behalf of Hollenbeck, Scott" mailto:regext-boun...@ietf.org> <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>> on behalf of shollenbeck=40verisign@dmarc.ietf.org <mailto:40verisign@dmarc.ietf.org> <mailto:40verisign@dmarc.ietf.org <mailto:40verisign@dmarc.ietf.org>>> wrote: I kinda prefer option A, too. Anything we can do to make this easier will be time well spent. Scott -Original Message- From: regext mailto:regext-boun...@ietf.org> <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>>> On Behalf Of Gould, James Sent: Thursday, June 8, 2023 8:14 AM To: a...@hxr.us <mailto:a...@hxr.us> <mailto:a...@hxr.us <mailto:a...@hxr.us>>; regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org <mailto:regext@ietf.org>> Subject: [EXTERNAL] Re: [regext] Thoughts on the fundamental premise of JSContact 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. Andy, I believe creating a simple RDAP extension for contacts (Path-forward #A) is best. jCard and JSContact are much more generic and complex than what is needed. The mandatory UID field of JSContact is a perfect example of how the intended purpose of JSContact does not meet the needs of RDAP. For EPP ther
Re: [regext] Thoughts on the fundamental premise of JSContact
xt@ietf.org> <mailto:regext@ietf.org <mailto:regext@ietf.org>> https://secure- web.cisco.com/1r4Wi1- NPZBDqwpyLN6BxTpMoPRLa8GfwJ0j1gqmlklT5Ok3AjIAaFP3TjMCZ5ao98ZKUJ1 hKPGL1sxyv6NdmSgCCyD- 7Z9SYuGOOLELVXwGcPY0AYQDIeEIyiwSnr9VIir2A2BTkgn6fpDWDJWGlWL7j9oF oH4vmwJ_VYuEaJlsr1iX72WbrV_0Ya8DIvSfDfISv_7NpvKNAlayyyCWXILPieLtSebH rY7lOiODr2ZLlStWZpV9XGXawNWfvF_5cLg6lfsRRXO_EKDXLVEr_Uurc9Zdif8Ge7 aqcVHVETkI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1r4Wi1- <https://secure-web.cisco.com/1r4Wi1-> NPZBDqwpyLN6BxTpMoPRLa8GfwJ0j1gqmlklT5Ok3AjIAaFP3TjMCZ5ao98ZKUJ1 hKPGL1sxyv6NdmSgCCyD- 7Z9SYuGOOLELVXwGcPY0AYQDIeEIyiwSnr9VIir2A2BTkgn6fpDWDJWGlWL7j9oF oH4vmwJ_VYuEaJlsr1iX72WbrV_0Ya8DIvSfDfISv_7NpvKNAlayyyCWXILPieLtSebH rY7lOiODr2ZLlStWZpV9XGXawNWfvF_5cLg6lfsRRXO_EKDXLVEr_Uurc9Zdif8Ge7 aqcVHVETkI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> ___ regext mailing list regext@ietf.org <mailto:regext@ietf.org> https://secure-web.cisco.com/1OAGvSd9H4h0ijUg1A6- <https://secure-web.cisco.com/1OAGvSd9H4h0ijUg1A6-> MaM68B1vOz2W1zKheEe_0ol58g9xYv_wGI2c2tx1GzuzRbstRb4oF- dTkLGkHYxptjN4T9WC16Q2mkDC0WfOn6fLJ3N9eaIxfwEjoNYO1x5yNGfhEjOwq 4qr54zFjFUSMhSii3U4P3FakBlolgVM0L6XoiIIQeMZu_PdjXR1gk5aQ2zvn8b8z_g9- 5FW- JEUVkDSgcrfXVc3_N4zRAzJeqS_Lfo1V07YlbVh9_iTZ9jFLjR6rpgi6eWw0K_THq3x DICY_XH4GYmuvSApdDefCnkU/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Fl istinfo%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 -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Thoughts on the fundamental premise of JSContact
perties that you want to ignore. But we could create an answer using RDAP extensions that signal profiles of jCard and/or JSContact. These profiles would explicitly list allowable items in jCard and JSContact. And should a registry come along that needs to express the crypto wallet of contacts, it is easy enough to create new profiles. [ML] If needed, I would support this proposal. Path-forward #C: Both #A and #B [ML] Does it mean that three contact representations (or two of them) could be inclued in an RDAP response at the same time ? If so, it doesn't make sense to me that server includes in the response two (or more) representations of the same information (regardless they are object-oriented or not) . Best, Mario -andy ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-16.txt
Hi all, this new version addresses the outcome of the discussion about redacting JSContact uid in RDAP. The examples have been updated to be compliant with last version of JSContact spec. Have not yet removed transition stages altogether but I have partially adjusted them to make the transition simpler. Would like to collect more feedback on this matter before changing the document significantly. Any feedback is welcome. Best, Mario Messaggio Inoltrato Oggetto: New Version Notification for draft-ietf-regext-rdap-jscontact-16.txt Data: Tue, 06 Jun 2023 04:50:33 -0700 Mittente: internet-dra...@ietf.org A: Gavin Brown , Mario Loffredo A new version of I-D, draft-ietf-regext-rdap-jscontact-16.txt has been successfully submitted by Mario Loffredo and posted to the IETF repository. Name: draft-ietf-regext-rdap-jscontact Revision: 16 Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses Document date: 2023-06-06 Group: regext Pages: 25 URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-16.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-jscontact-16 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 https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [EXTERNAL] Re: jCard to JSContact transition
Hi Jasdip and others, I strongly apologize for replying to this post with big delay but I have been very busy with JSContact and reverse search docs and other business from .it. After having concluded the discussion on how to redact the uid property, would like to resume and finalize the discussion on this topic. As I promised, have made some tests to estimate the size increase of the RDAP response when JSContact is returned along with jCard. Think it could be helpful to have a comprehensive overview. For the sake of obtaining an accurate measure, I purged the responses of notices, remarks and extensions and compacted the JSON content to exclude unnecessary characters (i.e. spaces, nelines) from the bytes count. First I found out that jscard is twice as big as jcard on average. In .it RDAP responses, the size of a jscard is a about 800 bytes whilst jcard is about 400 bytes long. This shouldn't sound weird. In fact, as opposed to JSContact, jCard doesn't include the property names because basically it's a JSON transliteration of a positional notation. I could not test other RDAP servers implementing JSContact but I don't think the results would be much different since in general RDAP makes use of the same subset of JSContact data. Then I took a domain with five contacts (i.e. one registrant, one admin and three techs) which corresponds to a common .it case. The response including only jCard was long about 3,5 Kb. This means that providing both the formats together makes the RDAP response larger more than twice. Maybe the size increment can't be a concern but I'm still convinced that it would sound pretty unusual to the client to get more than twice the response as before without negotiation. What do you think ? Best, Mario Il 04/04/2023 00:18, Jasdip Singh ha scritto: Hi. If the response size increase is not a concern when both jCard and JSContact objects are returned for some time, it seems Andy’s proposal (option 3) is the way to go. IMO, it keeps things simple without having to worry about which query parameter to set on the client side. Additionally, a server could simply send back a notice as to when jCard would be sunset from its side. As was mentioned previously, agree that a server couldn’t definitively measure when the client demand for jCard goes to zero by looking at the proposed query parameters. Instead, the server would decide unilaterally with sufficient forewarning to clients. Jasdip *From: *regext on behalf of Mario Loffredo *Date: *Monday, April 3, 2023 at 5:32 AM *To: *Rick Wilhelm , Andy Newton *Cc: *Marc Blanchet , "regext@ietf.org" *Subject: *Re: [regext] [EXTERNAL] Re: jCard to JSContact transition Hi Rick, please find my comments below. Il 01/04/2023 03:03, Rick Wilhelm ha scritto: I think that I’m leaning towards Andy’s approach, but I haven’t soak this thinking for very long. Perhaps it’s useful to go back to one of the original motivations for the draft. As I recall, programmers, especially client-side, have been known to have difficulty with JCard (for various reasons). Therefore, a “more modern” approach using JSContact is being proposed. So… A server presently has to support JCard and theoretically MAY support JSContact. If a client encounters such a server, and detects that the server supports JSContact, then it would be able to reliably ignore the JCard that is returned and instead use code that parses JSContact and be on its merry way. A key difference between Mario’s (2) and Andy(3) is basically a negotiation step. While I understand the benefit of “smaller response” proposed by (2), it seems that the negotiation step (with its round trips) would overwhelm that. And perhaps lead to odd situations (race conditions?) if the server is responding inconsistently. On balance, to me the cost of some extra bytes on the wire is cheap compared to the additional client and server code complexity, and the server load of the extra connection. Interested in others thoughts. [ML] Up to now, we have always followed the philosophy that an addtional feature must be provided by the server on demand. I would keep it also in this case so I would make the submission of jscard parameter the condition to receive JSContact. In my opinion, it's useless to provide the same information twice in two different formats simultaneously because the client will always use only one. Furthermore, providing the contact information in two formats increases the risk of inconsistencies between them. Please take a look at the change on the current approach I proposed to Andy and say if it works for you too. Best, Mario Thanks Rick *From: *regext <mailto:regext-boun...@ietf.org> on behalf of Andrew Newton <mailto:a...@hxr.us> *Date: *Saturday, April 1, 2023 at 6:27 AM
Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
The draft-ietf-jsonpath-base GitHub project includes some Ruby code to test JSONPath expressions against the defined syntax. But I don't know Ruby. Maybe a Ruby programmer in this WG could hopefully find out and test a JSONPath expression compliant with the jsonpath-base syntax and able to select an entity with a given role without assuming that the role is in the first position of the roles array. Best, Mario Il 26/04/2023 21:05, Gould, James ha scritto: I don't believe we're using advanced features of JSONPath in draft-ietf-regext-rdap-redacted and jsonpath.com has been used to validate the included examples. If there is a better tool to use, please let me know and I'll validate the examples with it. Otherwise, I believe we can continue to leverage jsonpath.com. Thanks, -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
Hi Andy,
Il 26/04/2023 17:55, Andrew Newton ha scritto:
I see in the implementation section of the draft there is a test
server that lists the redactions.
However, has anybody taken any real output from a DNR and INR server
and run some JSONPath expressions on them?
Doing so would help to prove out this spec.
Think the main problem is that AFAIK there aren't JSONPath online
testers fully compliant with jsonpath-base :-(
I have used some of them thus far (e.g. jsonpath.com,
jsonpath.curiousconcept.com/) but they refer to proprietary
implementations sharing only the basic features with jsonpath-base.
Just to be sure, have also tested on those sites some advanced JSONPath
expressions included in jsonpath-base but they returned no results.
Mario
-andy
On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo
wrote:
Il 26/04/2023 02:16, Tom Harrison ha scritto:
On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote:
The document editors have indicated that the following document is
ready for submission to the IESG to be considered for publication as
a Proposed Standard:
Redacted Fields in the Registration Data Access Protocol (RDAP) Response
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/
Please indicate your support or no objection for the publication of
this document by replying to this message on list (a simple “+1” is
sufficient).
If any working group member has questions regarding the publication
of this document please respond on the list with your concerns by
close of business everywhere, Monday, 1 May 2023.
If there are no objections the document will be submitted to the
IESG.
The Document Shepherd for this document is Gustavo Lozano Ibarra.
Looks good overall, some minor comments/suggestions.
Per previous mail from Pawel and Mario, some of the JSON path
expressions are not quite right for entities that have multiple roles.
There are some issues with the guidance added to the document to
account for this, though, and some further updates in this space that
would be useful. (We rely on entities having multiple roles in our
server implementation at the moment, for reference, and returning a
copy of each entity per role as a workaround is not ideal,
particularly when addressing the comments here shouldn't be
difficult.) To summarise these issues (mostly along the lines of the
comments from Pawel and Mario):
- The first example use of prePath has a value of:
$.entities[?(@.roles[0]=='administrative')]
But all that a client can infer from this path is that all entities
with "administrative" as their first role have been removed. Since
there are no guarantees around ordering of roles within an entity,
this doesn't necessarily mean that all entities with
"administrative" as one of their roles have been removed from the
resulting object. It would be better to use a more general
expression in this example (and the others like it) that captured
the intent more clearly. Per earlier mail from Pawel, something
like:
$.entities[?(@.roles[*]=='administrative')]
should do the job, though I wasn't able to determine the syntax
that would be acceptable for draft-ietf-jsonpath-base.
[ML] Per what is reported in Sections 2.3.5.1 (filter selector syntax)
and 2.3.3.1 (index selector syntax), it seems to me that wildcard is not
accepted.
The only acceptable values are integers (e.g. 0, 1, -1)
Neither any of the pre-defined functions seems helpful.
Looking at the examples in section 2.3.5.3, $.entities[?@.roles[?@ ==
'administrative]] could work maybe.
Another solution might be using the indexOf function that is defined by
some JSONPath implementations such as JSONPath.com and should be
registered as Function Extension (see Section 3.2) :
$.entities[?(@.roles.indexOf('administrative')!=-1)] //tested on
jsonpath.com
Anyway, the indexOf syntax should be redefined to be compliant with the
jsonpath-base syntax:
$.entities[?indexOf(@.roles,'administrative')!=-1]
Best,
Mario
- Section 5.2 at point 4 has:
When an entity has multiple roles, include "redacted" members
for each role using the role index. This will result in
duplicate "redacted" members, but will enable the client to
treat redaction consistently when there is a single role per
entity or multiple roles per entity.
It's not clear why this advice is present, when compared with e.g.
having the redacted members be a mapping from the server's
policies. For example, if the policy is that administrative
contacts not be returned, then a single "redacted" entry with a
prePath like "$.entities[?(@.roles[*]=='administrative')]" clearly
conveys that message to the client, and the client will understand
that those entities will be removed regardless of any additional
r
Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
tity with a technical role is omitted, then the first expression (though with 'roles[*]' instead of 'roles[0]') conveys that message more clearly than removal by way of index. (If the server's behaviour can't be conveyed by way of a JSON path, e.g. where an entity is omitted because they have opted out of being included in responses, then simply omitting the prePath and relying on a specific registered redacted name for the behaviour would make things clearer for the client than presenting an entity index that they can't resolve/use.) - Section 5.1 at point 1 has: When the server is using the Redaction By Removal Method (Section 3.1) or the Redaction by Replacement Value Method (Section 3.4) with an alternate field value, the JSONPath expression of the "prePath" member will not resolve successfully with the redacted response. The client can first key off the "name" member for display logic and utilize a template RDAP response overlaid with the redacted response to successfully resolve the JSONPath expression. There is an earlier thread where the "template RDAP response" is discussed, but it was noted there that it would likely be difficult to construct a one-size-fits-all template response. I think that's correct, given the flexibility of the underlying data format, but that in turns means that a "template RDAP response" would have to be generated on a per-server basis (something that was also flagged in that thread). There's no guidance for clients (or servers) on this point, though. Omitting the last sentence here will address the problem. - Also on section 5.1 point 1, the prePath expression will sometimes resolve 'successfully' when evaluating the redacted response, in the sense that it can be applied to the response and will return a result. For example, if the first technical-role entity is redacted by removal, but the object contains two technical-role entities, then the prePath will resolve to the second technical-role entity. This could be confusing for implementors, particularly given that the other JSONPath expressions will resolve correctly when evaluated against the redacted response. Some extra text here clarifying that the expression may evaluate 'successfully', but not 'correctly', would be useful. - (Another way of addressing all of the above is to remove prePath altogether, given that it's optional, and given that in most cases servers should use registered redacted names anyway, the descriptions for which can document the associated behaviour clearly and unambiguously.) In the definition for "name" in the "redacted" member, in section 4.2, the text has "[t]he logical name is defined using an object with a 'type' field denoting a registered redacted name (see Section 6.2)". The document uses various names in the examples (e.g. "Administrative Contact" in figure 1) without registering them, though. Registering those names would address the problem, or alternatively the "description" field for unregistered names could be used in the examples instead. Section 6.2 has: Two new JSON Values Registry Type field values are used to register pre-defined redacted name and reason values: "redacted name": Redacted name being registered. The registered redacted name is referenced using the "type" field of the redacted "name" field. "redacted reason": Redacted reason being registered. The registered redacted reason is referenced using the "type" field of the redacted "reason" field. "redacted expression language": Redacted expression language being registered. The registered redacted expression language is referenced using the "pathLang" field. The following values should be registered by the IANA in the RDAP JSON Values Registry described in [RFC7483]: ... This would read better if the first sentence took account of the "redacted expression language" registration as well, or alternatively if similar text was added after the "redacted reason" entry. -Tom ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
+ 1 Mario Il 17/04/2023 15:27, Antoin Verschuren ha scritto: The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: Redacted Fields in the Registration Data Access Protocol (RDAP) Response https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-redacted/11/ Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient). If any working group member has questions regarding the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 1 May 2023. If there are no objections the document will be submitted to the IESG. The Document Shepherd for this document is Gustavo Lozano Ibarra. Thanks, Jim and Antoin REGEXT WG Co-Chairs ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: [Ext] Re: Redacting JSContact uid in RDAP - Updated
Hi all, willing to finalize the discussion about how to redact JSContact uid in RDAP, I first would like to thank everyone who has provided feedback. Really appreciated it. SInce it seems to me that no option has collected the largest consensus, I would like to make a new proposal that hopefully will be more widely shared. The proposal preserves the mandatory constraint on uid and doesn't introduce new redaction methods. Assuming that an RDAP operator should be free to use any of the uid formats allowed, the redaction method might differ accordingly. In particular, I envisage two methods could be used. If an RDAP operator opted for the free-text format, the Empty Value method would work better. If the UUID format is selected, the Replacement Value method using the nil UUID as replacing value is the most appropriate in my opinion. Don't find a reason to register a specific URN value when an unspecified value already exists and considering that what really matters is not the returned value but rather that a related item is added to the redacted array. Neither we really need to add specific redaction methods because "Replacement Value" already fits the case of replacing the original value with another one. An URI value could be redacted by using any of the two methods above. For example, if the uid was usually set to the URL of the RDAP entity related to the contact (e.g. "https://example.com/rdap/entity/XYZ12345;), the redaction could consist in replacing the entity handle with a fixed literal (e.g "https://example.com/rdap/entity/X;). Still believe that overriding the mandatory constraint is the most correct approach from the conceptual perspective but couldn't be natively supported by libraries handling the JSContact format and strictly adhering to the specification. If there are no objections, I'll incorporate the proposal into rdap-jscontact. Best, Mario Messaggio Inoltrato Oggetto:Re: [regext] [Ext] Re: Redacting JSContact uid in RDAP - Updated Data: Tue, 4 Apr 2023 12:44:17 +0200 Mittente: Mario Loffredo A: Gustavo Lozano Ibarra , Andrew Newton CC: Hollenbeck, Scott , regext@ietf.org Hi Gustavo, thanks for you comment. For the sake of limiting the implications of rdap-jscontact on rdap-redacted, just checked on some web sites providing UUID generators that "nil UUID" and "empty UUID" are synonyms. Since rdap-redacted defines "redaction by Empty Value" (rather than empty string), wonder if we could consider the setting of the uid property to an Empty/nill UUID (i.e. "----") as an usage of such a method. As a result, the same redaction method could be used to redact uid values in both free-text and UUID formats. Another possible solution is to define in rdap-redacted a registry including the redaction methods. New redaction method names like those suggested by Gustavo could be defined by future documents (rdap-jscontact primarily) that can't find a match among the methods listed in rdap-redacted. Thoughts? Best, Mario Il 04/04/2023 04:24, Gustavo Lozano Ibarra ha scritto: Hi Mario, et. Al., Comments inline. Regards, Gustavo On 4/2/23, 11:38 PM, "regext on behalf of Mario Loffredo" wrote: HI Andy, Il 31/03/2023 23:36, Andrew Newton ha scritto: > If the uid can be free text according to JSContact, why do we need to > override that? RDAP servers can just put random text in that field, > which has the same effect of the UUID URN. > > That said, I like Gavin's idea. I could live with Option 4 or Option 3. [ML] I would have no objection to use Option 3 or Option 4 but both of them require to define a new redaction method because none of those currently defined can be used in those cases. GL - Correct, and I think that having those new redaction methods defined in draft-ietf-regext-rdap-redacted is a must. I have been in conversations with users of RDDS (a term in the gTLD world that means the service used to consume registration data) in which there is a desire to differentiate between: * No data was provided in the response because no data exists in the server's database. * Data exists in the database, but it was redacted in the response. * The data provided in the response is the actual data in the database, even if the semantics of the value are non-customary, for example, a registrant providing "REDACTED FOR PRIVACY" (a well-known string used in Whois to indicate redaction) as their name. The "redacted" member defined in draft-ietf-regext-rdap-redacted provides the signaling mechanism that satisfies the requirements above. If option 3 is selected with a random value, a signal is needed to differentiate between data persisted in the database and randomly generated values. Maybe we can add "redaction by random v
[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-21.txt
Hi all, this new version includes the following changes: - added a sentence about servers signaling the unsupported reverse searches as recommended during WGLC; - replaced "$.." with "$." into the JSONPath expressions to make them select only the directly-associated entities; - clarified that the registry group the new registries must be added to is "Registration Data Access Protocol (RDAP)" as requested by IANA; - removed an unused normative reference to RFC7480. Best, Mario Messaggio Inoltrato Oggetto: New Version Notification for draft-ietf-regext-rdap-reverse-search-21.txt Data: Mon, 17 Apr 2023 23:52:08 -0700 Mittente: internet-dra...@ietf.org A: Mario Loffredo , Maurizio Martinelli A new version of I-D, draft-ietf-regext-rdap-reverse-search-21.txt has been successfully submitted by Mario Loffredo and posted to the IETF repository. Name: draft-ietf-regext-rdap-reverse-search Revision: 21 Title: Registration Data Access Protocol (RDAP) Reverse Search Document date: 2023-04-17 Group: regext Pages: 22 URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-21.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-reverse-search-21 Abstract: The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [EXTERNAL] Re: jCard to JSContact transition
Hi Andy,
please find my responses below.
Il 10/04/2023 15:32, Andrew Newton ha scritto:
Comments below.
On Fri, Apr 7, 2023 at 4:16 AM Mario Loffredo wrote:
Hi Andy,
Il 06/04/2023 16:36, Andrew Newton ha scritto:
On Thu, Apr 6, 2023 at 9:56 AM Mario Loffredo wrote:
[ML] Sorry for the delay in replying and thanks for this.
Really there are some documents under discussion that would be
eventually affected.
But I wonder where it's stated that query parameters should/must not be
preserved in redirections.
Do you refer to a generally adopted practice or to an IETF document ?
I took a look at RFC 9110 and didn't find specific statements about that.
Because unless the server issuing the redirects explicitly preserves
the query parameters in the new URL, they will not be preserved. My
quick glance of 9110 does not say that query parameters are preserved
so I don't know how a conclusion can be drawn that they are. But we
don't have to be so theoretical about it. We can just try it:
$ curl -vhttps://rdap-bootstrap.arin.net/bootstrap/autnum/2830?someparam=foo
* Trying 199.212.0.160:443...
* Connected to rdap-bootstrap.arin.net (199.212.0.160) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=Virginia; L=Chantilly; O=American Registry for
Internet Numbers, Ltd.; CN=*.arin.net
* start date: Aug 4 00:00:00 2022 GMT
* expire date: Sep 4 23:59:59 2023 GMT
* subjectAltName: host "rdap-bootstrap.arin.net" matched cert's "*.arin.net"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
GET /bootstrap/autnum/2830?someparam=foo HTTP/1.1
Host: rdap-bootstrap.arin.net
User-Agent: curl/7.79.1
Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 302
< Date: Thu, 06 Apr 2023 14:23:33 GMT
< Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
< Location:https://rdap.db.ripe.net/autnum/2830
< Content-Length: 0
< Access-Control-Allow-Origin: *
<
* Connection #0 to host rdap-bootstrap.arin.net left intact
-andy
[ML] AFAIU from RFC 9110, removing the query part from the target URI is
a misinterpretation of redirection .
If the original target URI includes the query part, it should be
preserved in the new target URI similarly to the path part.
I'm not sure how such a conclusion can be made especially given
current deployment of the technology does not support it.
[ML2] For some reasons:
- it seems to me there is no syntactical constraint preventing from
including the query in URIs used in redirection. If it's allowed, why
should the query be omitted ?
- searching on the web, I found that preserving the query in
redirection depends on implementations
- some official documents, such as RFC 6749 and OpenID Connect Core,
present URIs used in redirection including query parameters
Furthermore, URI's are about identifying resources. RFC 3986 notes
this about query parameters:
"The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
(if any)."
[ML2] Don't think this case is different. There are resources providing
the contact information in jCard and resources providing the contact
information in JSContact.
What would be the difference if the server allowed to request for
JSContact through an optional path segment instead of a query parameter
? (e.g. https://example.com/rdap/domain/{domain name}[/jscard])
The query parameter can be used in both lookups and searches, and
doesn't require to introduce new path segments.
Besides, the use of the jscard query parameter is preferrable as it can
be propagated to the possible related links included in the RDAP response.
Finally, some documents in discussion in this WG and already published
as RFC envisage the use of query parameters and don't see drawbacks in
keeping this way.
A redirect indicates that one resource defined by a URI can be found
by using another URI. Path and query help identify a resource and
there is no defined preservation of either.
[ML2] Think that servers should preserve the original request. If, as
you wrote, path and query contribute to identify a resource, removing
the query would alter the original request.
Anyway, if needed, rdap-jscontact could include text stating that the
jscard parameter must be pres
Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
Il 07/04/2023 18:56, Jasdip Singh ha scritto: On 4/5/23, 12:56 PM, "Mario Loffredo" mailto:mario.loffr...@iit.cnr.it>> wrote: [SAH] Nit: as alluded to by Jasdip above, RFC 7231 has been obsoleted by RFC 9110. The 501 text is 9110 is consistent with 7231, but I don’t think it’s limited to an invalid method. If the operative text is “the server does not support the functionality required to fulfill the request”, the response can be returned for *any* condition in which the server does not support the functionality required to fulfill the request. It doesn’t say that “the server does not support the requested method”. I still believe that 501 would be the best response. After rereading the text, I agree with Scott. [ML] Just to understand better, daes it mean that an RDAP server should support additional lookups and searches to those really implemented with the only purpose of returning an error ? [SAH] No. The point I'm trying to make is that if a client sends a valid request to an RDAP server, and that request can't be processed because the requested functionality isn't supported, then a 501 response is appropriate. [ML] It's unclear to me what "functionality" (as well as "unsupported query type") means. Excluding the HTTP methods and the endpoints, what remains is a functionality requested by clients through either a query parameter or an header but unsupported/unknown parameters/headers are simply ignored. Is there something else ? [SAH] A path segment? Imagine sending something like this to a domain name registry: https://example.com/rdap/autnum/12 <https://example.com/rdap/autnum/12> It's RDAP-valid, but a domain name registry probably doesn't support autonomous system number lookup functionality. [ML] Don't know if I'm the only one but I think it's an unpractical recommendation. I admit that 501 is more explanatory because, taking your example, 404 would be returned when the autnum lookup is unsupported and when autnum/12 is not found but a server can provide the clients with information about the supported features by other means. Conversely, exposing useless endpoints on the web means not only to require an unnecessary implementation effort but also to enlarge the surface of cyberattacks. Definitely, the servers need only to handle the endpoints they really listen at and the query parameters or request headers they really support. That said, if I'm the only dissonant voice in discussion, I'll add that recommendation to rdap-reverse-search. [JS] Mario, I think it would be a good idea to add verbiage for 501 (Not Implemented) in this draft since we have a precedence in RFC 9082 and that does not seem to cover new query types like reverse search. Then, the draft can proceed to the next step. :) No worries, Jasdip. I'll update the document as soon as the WGLC is ended. Does it work the following ? *Servers **MUST**return an HTTP 501 (Not Implemented) **[RFC9110]**response to inform clients of unsupported reverse searches.* Cheers, Mario Cheers, Jasdip -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [EXTERNAL] Re: jCard to JSContact transition
Hi Andy, Il 06/04/2023 16:36, Andrew Newton ha scritto: On Thu, Apr 6, 2023 at 9:56 AM Mario Loffredo wrote: [ML] Sorry for the delay in replying and thanks for this. Really there are some documents under discussion that would be eventually affected. But I wonder where it's stated that query parameters should/must not be preserved in redirections. Do you refer to a generally adopted practice or to an IETF document ? I took a look at RFC 9110 and didn't find specific statements about that. Because unless the server issuing the redirects explicitly preserves the query parameters in the new URL, they will not be preserved. My quick glance of 9110 does not say that query parameters are preserved so I don't know how a conclusion can be drawn that they are. But we don't have to be so theoretical about it. We can just try it: $ curl -vhttps://rdap-bootstrap.arin.net/bootstrap/autnum/2830?someparam=foo * Trying 199.212.0.160:443... * Connected to rdap-bootstrap.arin.net (199.212.0.160) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (OUT), TLS handshake, Client hello (1): * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: C=US; ST=Virginia; L=Chantilly; O=American Registry for Internet Numbers, Ltd.; CN=*.arin.net * start date: Aug 4 00:00:00 2022 GMT * expire date: Sep 4 23:59:59 2023 GMT * subjectAltName: host "rdap-bootstrap.arin.net" matched cert's "*.arin.net" * issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1 * SSL certificate verify ok. GET /bootstrap/autnum/2830?someparam=foo HTTP/1.1 Host: rdap-bootstrap.arin.net User-Agent: curl/7.79.1 Accept: */* * Mark bundle as not supporting multiuse < HTTP/1.1 302 < Date: Thu, 06 Apr 2023 14:23:33 GMT < Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips < Location:https://rdap.db.ripe.net/autnum/2830 < Content-Length: 0 < Access-Control-Allow-Origin: * < * Connection #0 to host rdap-bootstrap.arin.net left intact -andy [ML] AFAIU from RFC 9110, removing the query part from the target URI is a misinterpretation of redirection . If the original target URI includes the query part, it should be preserved in the new target URI similarly to the path part. In addition, if I correctly understood RFC 7484 , the RDAP bootstrap method consists in replacing only the base RDAP URL of the URI. Best, Mario -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [EXTERNAL] Re: jCard to JSContact transition
Il 04/04/2023 18:48, Andrew Newton ha scritto: On Mon, Apr 3, 2023 at 3:18 PM Jasdip Singh wrote: Hi. If the response size increase is not a concern when both jCard and JSContact objects are returned for some time, it seems Andy’s proposal (option 3) is the way to go. IMO, it keeps things simple without having to worry about which query parameter to set on the client side. Additionally, a server could simply send back a notice as to when jCard would be sunset from its side. As was mentioned previously, agree that a server couldn’t definitively measure when the client demand for jCard goes to zero by looking at the proposed query parameters. Instead, the server would decide unilaterally with sufficient forewarning to clients. (replying to Jasdip just because this is a good place to do it)... There is one other issue with the query parameters in that they won't survive redirects. This is the issue with attempting to encode client capabilities into URIs. If we want to encode a client's capabilities (e.g. this client supports JSContact), then that should go into an HTTP header. Now, this is a general RDAP issue and not specific to this draft, but I think this is another reason why the draft should drop the query parameters. -andy ps. Having done a little looking about using HTTP headers for client capabilities, one tried and true method would be to use a media type in the accepts header that supports parameters. Here's an example: https://www.iana.org/assignments/media-types/application/ld+json [ML] Sorry for the delay in replying and thanks for this. Really there are some documents under discussion that would be eventually affected. But I wonder where it's stated that query parameters should/must not be preserved in redirections. Do you refer to a generally adopted practice or to an IETF document ? I took a look at RFC 9110 and didn't find specific statements about that. Best, Mario ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
Hi Scott, please find my response below. Il 05/04/2023 16:43, Hollenbeck, Scott ha scritto: -Original Message- From: Mario Loffredo Sent: Wednesday, April 5, 2023 10:04 AM To: Hollenbeck, Scott ; a...@hxr.us Cc: jasd...@arin.net; regext@ietf.org Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search- 20 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. Il 05/04/2023 14:40, Hollenbeck, Scott ha scritto: -Original Message- From: Mario Loffredo Sent: Wednesday, April 5, 2023 4:24 AM To: Andrew Newton ; Hollenbeck, Scott Cc: jasd...@arin.net; regext@ietf.org Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search- 20 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 Scott and Andy, Il 04/04/2023 18:33, Andrew Newton ha scritto: On Tue, Apr 4, 2023 at 9:20 AM Hollenbeck, Scott wrote: [SAH] Nit: as alluded to by Jasdip above, RFC 7231 has been obsoleted by RFC 9110. The 501 text is 9110 is consistent with 7231, but I don’t think it’s limited to an invalid method. If the operative text is “the server does not support the functionality required to fulfill the request”, the response can be returned for *any* condition in which the server does not support the functionality required to fulfill the request. It doesn’t say that “the server does not support the requested method”. I still believe that 501 would be the best response. After rereading the text, I agree with Scott. [ML] Just to understand better, daes it mean that an RDAP server should support additional lookups and searches to those really implemented with the only purpose of returning an error ? [SAH] No. The point I'm trying to make is that if a client sends a valid request to an RDAP server, and that request can't be processed because the requested functionality isn't supported, then a 501 response is appropriate. [ML] It's unclear to me what "functionality" (as well as "unsupported query type") means. Excluding the HTTP methods and the endpoints, what remains is a functionality requested by clients through either a query parameter or an header but unsupported/unknown parameters/headers are simply ignored. Is there something else ? [SAH] A path segment? Imagine sending something like this to a domain name registry: https://example.com/rdap/autnum/12 It's RDAP-valid, but a domain name registry probably doesn't support autonomous system number lookup functionality. [ML] Don't know if I'm the only one but I think it's an unpractical recommendation. I admit that 501 is more explanatory because, taking your example, 404 would be returned when the autnum lookup is unsupported and when autnum/12 is not found but a server can provide the clients with information about the supported features by other means. Conversely, exposing useless endpoints on the web means not only to require an unnecessary implementation effort but also to enlarge the surface of cyberattacks. Definitely, the servers need only to handle the endpoints they really listen at and the query parameters or request headers they really support. That said, if I'm the only dissonant voice in discussion, I'll add that recommendation to rdap-reverse-search. Best, Mario Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
No worries Jasdip. I'll reply to that post. Thanks Mario Il 05/04/2023 16:46, Jasdip Singh ha scritto: Hello Mario, I have attached my comment to Scott’s comment in the other thread. :) Thanks, Jasdip *From: *Mario Loffredo *Date: *Wednesday, April 5, 2023 at 4:07 AM *To: *Jasdip Singh , Andy Newton *Cc: *"regext@ietf.org" *Subject: *Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20 Il 04/04/2023 17:37, Jasdip Singh ha scritto: On Mon, Apr 3, 2023 at 7:57 AM Jasdip Singh <mailto:jasd...@arin.net> wrote: What I gather from Andy’s suggestion is that 501 could also be returned for the reverse search queries that are not implemented (supported) on the server side. That said, your observation of applying HTTP 501 to unsupported request methods seems right. Not to muddle but wonder if we missed applying HTTP 501 correctly in RFC 9082? That is what I meant, but perhaps 405 is the more appropriate response. Kinda annoying that 9082 went through 2 IETF last calls and this wasn't caught. -andy AFAIU, RFC 7231 states that: - 404 must be returned to signal that the target resource is unknown to the server; The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists - 405 must be returned to signal that an HTTP method is unsupported on the target resource but known to the server; The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource - 501 must be returned to signal that an HTTP method is unknown to the server The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. Based on it, don't think rdap-reverse-search should add text to address these cases. As I wrote in my previous reply, the document had only to define the server operation when the client includes in the request an unsupported reverse search property or combination of reverse search properties. In this case, the server must return 400 (Bad Request). With regard to RFC 9082, my proposal is to remove the sentence in subject. [JS] If the intent vis-à-vis error codes is to differentiate a feature that is not implemented on the server side versus a bad request for an implemented feature, 400 (Bad Request) does not look like a good fit for the former since it is not a client error when a feature is not supported. Thanks to Mario, we learnt 501 (Not Implemented) is also not a good fit for the former since it is at the HTTP method level (GET in our case). That seems to leave 405 (Method Not Allowed) as a viable alternative to 501 since per RFC 9110, “The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource.” Irrespective, 501 looks like an errata for Section 1 in RFC 9082. [ML] Sorry Jasdip, but I didn't catch if your comment (or which part) is about the reverse search document or RFC 9082. With regard to the reverse search document, 400 looks to me the only one fitting the case. Surely it's a client error if the client includes in the query string either an unsupported or an invalid combination of reverse search properties. Just for example, .it RDAP server requires the client to always include "role" along with another supported reverse search property in a reverse search. The server may restrict the use of the reverse search feature based on its policy and the client must comply with those restrictions. Best, Mario Thanks, Jasdip ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo
Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
Il 05/04/2023 14:40, Hollenbeck, Scott ha scritto: -Original Message- From: Mario Loffredo Sent: Wednesday, April 5, 2023 4:24 AM To: Andrew Newton ; Hollenbeck, Scott Cc: jasd...@arin.net; regext@ietf.org Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search- 20 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 Scott and Andy, Il 04/04/2023 18:33, Andrew Newton ha scritto: On Tue, Apr 4, 2023 at 9:20 AM Hollenbeck, Scott wrote: [SAH] Nit: as alluded to by Jasdip above, RFC 7231 has been obsoleted by RFC 9110. The 501 text is 9110 is consistent with 7231, but I don’t think it’s limited to an invalid method. If the operative text is “the server does not support the functionality required to fulfill the request”, the response can be returned for *any* condition in which the server does not support the functionality required to fulfill the request. It doesn’t say that “the server does not support the requested method”. I still believe that 501 would be the best response. After rereading the text, I agree with Scott. [ML] Just to understand better, daes it mean that an RDAP server should support additional lookups and searches to those really implemented with the only purpose of returning an error ? [SAH] No. The point I'm trying to make is that if a client sends a valid request to an RDAP server, and that request can't be processed because the requested functionality isn't supported, then a 501 response is appropriate. [ML] It's unclear to me what "functionality" (as well as "unsupported query type") means. Excluding the HTTP methods and the endpoints, what remains is a functionality requested by clients through either a query parameter or an header but unsupported/unknown parameters/headers are simply ignored. Is there something else ? Mario Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
Hi Scott and Andy, Il 04/04/2023 18:33, Andrew Newton ha scritto: On Tue, Apr 4, 2023 at 9:20 AM Hollenbeck, Scott wrote: [SAH] Nit: as alluded to by Jasdip above, RFC 7231 has been obsoleted by RFC 9110. The 501 text is 9110 is consistent with 7231, but I don’t think it’s limited to an invalid method. If the operative text is “the server does not support the functionality required to fulfill the request”, the response can be returned for *any* condition in which the server does not support the functionality required to fulfill the request. It doesn’t say that “the server does not support the requested method”. I still believe that 501 would be the best response. After rereading the text, I agree with Scott. [ML] Just to understand better, daes it mean that an RDAP server should support additional lookups and searches to those really implemented with the only purpose of returning an error ? Best, Mario -andy -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
Il 04/04/2023 17:37, Jasdip Singh ha scritto: On Mon, Apr 3, 2023 at 7:57 AM Jasdip Singh <mailto:jasd...@arin.net> wrote: What I gather from Andy’s suggestion is that 501 could also be returned for the reverse search queries that are not implemented (supported) on the server side. That said, your observation of applying HTTP 501 to unsupported request methods seems right. Not to muddle but wonder if we missed applying HTTP 501 correctly in RFC 9082? That is what I meant, but perhaps 405 is the more appropriate response. Kinda annoying that 9082 went through 2 IETF last calls and this wasn't caught. -andy AFAIU, RFC 7231 states that: - 404 must be returned to signal that the target resource is unknown to the server; The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists - 405 must be returned to signal that an HTTP method is unsupported on the target resource but known to the server; The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource - 501 must be returned to signal that an HTTP method is unknown to the server The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. Based on it, don't think rdap-reverse-search should add text to address these cases. As I wrote in my previous reply, the document had only to define the server operation when the client includes in the request an unsupported reverse search property or combination of reverse search properties. In this case, the server must return 400 (Bad Request). With regard to RFC 9082, my proposal is to remove the sentence in subject. [JS] If the intent vis-à-vis error codes is to differentiate a feature that is not implemented on the server side versus a bad request for an implemented feature, 400 (Bad Request) does not look like a good fit for the former since it is not a client error when a feature is not supported. Thanks to Mario, we learnt 501 (Not Implemented) is also not a good fit for the former since it is at the HTTP method level (GET in our case). That seems to leave 405 (Method Not Allowed) as a viable alternative to 501 since per RFC 9110, “The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource.” Irrespective, 501 looks like an errata for Section 1 in RFC 9082. [ML] Sorry Jasdip, but I didn't catch if your comment (or which part) is about the reverse search document or RFC 9082. With regard to the reverse search document, 400 looks to me the only one fitting the case. Surely it's a client error if the client includes in the query string either an unsupported or an invalid combination of reverse search properties. Just for example, .it RDAP server requires the client to always include "role" along with another supported reverse search property in a reverse search. The server may restrict the use of the reverse search feature based on its policy and the client must comply with those restrictions. Best, Mario Thanks, Jasdip ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [EXTERNAL] Re: jCard to JSContact transition
Hi Jasdip,
please find my comments below.
Il 04/04/2023 00:18, Jasdip Singh ha scritto:
Hi.
If the response size increase is not a concern when both jCard and
JSContact objects are returned for some time, it seems Andy’s proposal
(option 3) is the way to go. IMO, it keeps things simple without
having to worry about which query parameter to set on the client side.
[ML] Based on my last proposal, the client needs to set only the jscard
parameter. It can be set just once and then can persist in the query
string for long until being removed.
On server side, a server must return jCard or JSContact along with some
response extensions depending on the jscard parameter.
Have implemented it on both sides and the required effort was not so
relevant.
Additionally, a server could simply send back a notice as to when
jCard would be sunset from its side. As was mentioned previously,
agree that a server couldn’t definitively measure when the client
demand for jCard goes to zero by looking at the proposed query
parameters. Instead, the server would decide unilaterally with
sufficient forewarning to clients.
[ML] Jasdip let me please remind you and everyone else that, at the time
this document was adopted, we decided to rename the draft in order to
put the focus on JSContact extension rather than on jCard deprecation.
We did it because most of us were uncertain about the jCard deprecation.
I'm very happy to see there is much less uncertainty now, but I still
don't think option 3 is the best way to go for the following reasons:
- conceptually, providing the same information in two formats at the
same time when just one is used doesn't make sense to me
- would evaluate how big could be the payload increment due to
duplicating the contact cards and related information, especially in
search responses. Maybe I'm wrong but it doesn't seem entirely
negligible to me. Will make some tests.
- think it would be useful for every server to gather some stats from
the logs to monitor the spread of JSContact
- last but not least, unsetting jCard unilaterally and with no evidence
that it will not break the response seems to me more disruptive for
clients than returning JSContact instead of jCard on demand.
Best,
Mario
Jasdip
*From: *regext on behalf of Mario Loffredo
*Date: *Monday, April 3, 2023 at 5:32 AM
*To: *Rick Wilhelm , Andy Newton
*Cc: *Marc Blanchet , "regext@ietf.org"
*Subject: *Re: [regext] [EXTERNAL] Re: jCard to JSContact transition
Hi Rick,
please find my comments below.
Il 01/04/2023 03:03, Rick Wilhelm ha scritto:
I think that I’m leaning towards Andy’s approach, but I haven’t
soak this thinking for very long.
Perhaps it’s useful to go back to one of the original motivations
for the draft.
As I recall, programmers, especially client-side, have been known
to have difficulty with JCard (for various reasons).
Therefore, a “more modern” approach using JSContact is being proposed.
So… A server presently has to support JCard and theoretically MAY
support JSContact.
If a client encounters such a server, and detects that the server
supports JSContact, then it would be able to reliably ignore the
JCard that is returned and instead use code that parses JSContact
and be on its merry way.
A key difference between Mario’s (2) and Andy(3) is basically a
negotiation step. While I understand the benefit of “smaller
response” proposed by (2), it seems that the negotiation step
(with its round trips) would overwhelm that. And perhaps lead to
odd situations (race conditions?) if the server is responding
inconsistently.
On balance, to me the cost of some extra bytes on the wire is
cheap compared to the additional client and server code
complexity, and the server load of the extra connection.
Interested in others thoughts.
[ML] Up to now, we have always followed the philosophy that an
addtional feature must be provided by the server on demand.
I would keep it also in this case so I would make the submission of
jscard parameter the condition to receive JSContact.
In my opinion, it's useless to provide the same information twice in
two different formats simultaneously because the client will always
use only one.
Furthermore, providing the contact information in two formats
increases the risk of inconsistencies between them.
Please take a look at the change on the current approach I proposed
to Andy and say if it works for you too.
Best,
Mario
Thanks
Rick
*From: *regext
<mailto:regext-boun...@ietf.org> on behalf of Andrew Newton
<mailto:a...@hxr.us>
*Date: *Saturday, April 1, 2023 at 6:27 AM
*To: *Mario Loffredo
<mailto:mario.loffr...@iit.cnr.it>
*Cc: *Marc Blanchet
<mailto:marc.blanc...@viagenie.ca>, regext@ietf.org
<mailto:regext@ietf.org>
*Subject: *[E
Re: [regext] [Ext] Re: Redacting JSContact uid in RDAP - Updated
Hi Gustavo,
thanks for you comment.
For the sake of limiting the implications of rdap-jscontact on
rdap-redacted, just checked on some web sites providing UUID generators
that "nil UUID" and "empty UUID" are synonyms.
Since rdap-redacted defines "redaction by Empty Value" (rather than
empty string), wonder if we could consider the setting of the uid
property to an Empty/nill UUID (i.e.
"----") as an usage of such a method.
As a result, the same redaction method could be used to redact uid
values in both free-text and UUID formats.
Another possible solution is to define in rdap-redacted a registry
including the redaction methods.
New redaction method names like those suggested by Gustavo could be
defined by future documents (rdap-jscontact primarily) that can't find a
match among the methods listed in rdap-redacted.
Thoughts?
Best,
Mario
Il 04/04/2023 04:24, Gustavo Lozano Ibarra ha scritto:
Hi Mario, et. Al.,
Comments inline.
Regards,
Gustavo
On 4/2/23, 11:38 PM, "regext on behalf of Mario Loffredo"
wrote:
HI Andy,
Il 31/03/2023 23:36, Andrew Newton ha scritto:
> If the uid can be free text according to JSContact, why do we need to
> override that? RDAP servers can just put random text in that field,
> which has the same effect of the UUID URN.
>
> That said, I like Gavin's idea. I could live with Option 4 or Option 3.
[ML] I would have no objection to use Option 3 or Option 4 but both of
them require to define a new redaction method because none of those
currently defined can be used in those cases.
GL - Correct, and I think that having those new redaction methods defined in
draft-ietf-regext-rdap-redacted is a must.
I have been in conversations with users of RDDS (a term in the gTLD world that
means the service used to consume registration data) in which there is a desire
to differentiate between:
* No data was provided in the response because no data exists in the server's
database.
* Data exists in the database, but it was redacted in the response.
* The data provided in the response is the actual data in the database, even if the
semantics of the value are non-customary, for example, a registrant providing
"REDACTED FOR PRIVACY" (a well-known string used in Whois to indicate
redaction) as their name.
The "redacted" member defined in draft-ietf-regext-rdap-redacted provides the
signaling mechanism that satisfies the requirements above.
If option 3 is selected with a random value, a signal is needed to differentiate between
data persisted in the database and randomly generated values. Maybe we can add
"redaction by random value" to draft-ietf-regext-rdap-redacted?
If option 4 is selected, I think adding a signal in the "redacted" member is also desired in order to have a central
place signaling all redactions in the response. It is straightforward for an implementer to understand that "redacted"
contains all redacted data elements, and they need to do "X" in the interface if a data element is defined as redacted.
If we go with option 4 without support in draft-ietf-regext-rdap-redacted, there would be this unique scenario that it's not in
the "redacted" member, but it's still redacted if you find the special value. Maybe we can "redaction by
placeholder value" to draft-ietf-regext-rdap-redacted?
Otherwise uid could be the only RDAP property that can be redacted
through a kind of placeholder value without being included in the
redacted array.
Do you agree about it ?
Option 1 leverages the Empty Value redaction method and free-text format
but it's likely that a JSContact implementation will check not only for
the not null constraint but also for the not empty constraint.
Therefore, even in this case and similarly to Option 2, a JSContact
implementation should distignuish cards used outside RDAP from those
used inside RDAP.
Option 2 doesn't need a new redaction method and enbales an RDAP server
to set the uid property as it sees fit:
- assigning it with a valid value and, when needed, redacting it by the
Removal method
- omitting the uid property
That being said, if the WG agreed about adding a new redaction method to
macth Option 3 and Option 4, I wouldn't object.
Best,
Mario
> -andy
>
> On Fri, Mar 31, 2023 at 11:52 PM Mario Loffredo
> wrote:
>> Hi Scott,
>>
>> Il 31/03/2023 14:32, Hollenbeck, Scott ha scritto:
>>>> -Original Message-
>>>> From: regext On Behalf Of Mario Loffredo
>>>> Sent: Friday, March 31, 2023 7:45 AM
>>>> To:regext@ietf.org
>>>>
Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
Hi Andy and Jasdip, Il 03/04/2023 22:30, Andrew Newton ha scritto: On Mon, Apr 3, 2023 at 7:57 AM Jasdip Singh wrote: What I gather from Andy’s suggestion is that 501 could also be returned for the reverse search queries that are not implemented (supported) on the server side. That said, your observation of applying HTTP 501 to unsupported request methods seems right. Not to muddle but wonder if we missed applying HTTP 501 correctly in RFC 9082? That is what I meant, but perhaps 405 is the more appropriate response. Kinda annoying that 9082 went through 2 IETF last calls and this wasn't caught. -andy AFAIU, RFC 7231 states that: - 404 must be returned to signal that the target resource is unknown to the server; The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists - 405 must be returned to signal that an HTTP method is unsupported on the target resource but known to the server; The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource - 501 must be returned to signal that an HTTP method is unknown to the server The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. Based on it, don't think rdap-reverse-search should add text to address these cases. As I wrote in my previous reply, the document had only to define the server operation when the client includes in the request an unsupported reverse search property or combination of reverse search properties. In this case, the server must return 400 (Bad Request). With regard to RFC 9082, my proposal is to remove the sentence in subject. Best, Mario ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dott. 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://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
