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" <[email protected] <mailto:[email protected]>> 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" > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> on behalf > of [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> 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 <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> On Behalf >> Of Gould, James >> Sent: Thursday, June 8, 2023 8:14 AM >> To: [email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>; [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> 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 there >> is a EPP Contact Mapping in RFC 5733 that doesn't carry any extra weight of a >> more general-purpose contact / address book XML representation. The JSON >> should be straight forward to process in RDAP. The RDAP Contact Extension >> can directly support the contact information contained in the EPP Contact >> Mapping along with additional features needed for the RIRs, without the need >> for added bloat and complexity of a general-purpose contact representation. >> >> -- >> >> JG >> >> James Gould >> Fellow Engineer >> [email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> <applewebdata://13890C55-AAE8-4BF3-A6CE- >> B4BA42740803/[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> Verisign.com <http://secure- >> web.cisco.com/1AQ0PwiCZE6GyMJuDkvNZnO7kEZE7QUyFQUzzJhALD20VD5mP >> LMPQVlYIIvBIYT_gftye4v7KQKeOO1_wLBqvq7ejTHY4Y3vvgQdSoSvxGPczxeWuT >> tDEgMXtZrVDpqR9w- >> VyCV_B69qpyQvw7n8VTFxlB8S5lDMFs4BfxRE792dYJXe0ODoKoqfI29wzIvFaM1g >> MbPg_pnhWZY2bWx5MG9eXTFg4Z8LrFVvdjjoDUALhmEbdDBHkKuByQL4GG3Sh >> NvsoadHyeSw9BOlVrC0sJOVr1yxxUvwA4_3mkAVUeIQ/http%3A%2F%2Fverisigni >> nc.com%2F> >> >> On 6/7/23, 2:26 PM, "regext on behalf of Andrew Newton" <regext- >> [email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> <mailto:[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>> on behalf of [email protected] >> <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>>> wrote: >> >> 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, >> >> Very recently I have had the displeasure of implementing jCard for an RDAP >> client, and in so doing have taken a closer look at JSContact and have >> talked to >> a few people privately about it. Both I and they believed that JSContact >> would >> be much better than jCard. However, after looking at the JSContact spec, I >> don’t >> believe it is better and in some ways it is far more problematic. Therefore, >> I >> want to share my thoughts for discussion purposes. >> >> #1 JSContact uses JSON objects and is therefore better than jCard. >> >> Both I and a few people with whom I have discussed this issue have held this >> thought. It is true that JSContact uses JSON objects instead of the nested >> arrays >> found in jCard, but it does not use them in a way that makes JSContact >> easier to >> handle. Let me explain. >> >> Most of RDAP is straightforward JSON as would be found in very typical REST >> APIs. This makes serializing and deserializing JSON to and from data >> structures >> easy in most programming languages using well-known toolkits. I offer the >> following Java example, but these things exist in most programming languages: >> >> public class Link { >> private String href; >> private String value; >> @JsonProperty("type") >> private String mediaType; >> } >> >> Here, an RDAP link structure is represented. Some of the properties can be >> automatically serialized/deserialized and others are easy to use with simple >> annotations. >> >> By contrast, JSContact JSON objects are much more than simple JSON objects >> as found in RDAP. Here is an example of JSContact person >> titles: >> >> "titles": { >> "le9": { >> "kind": "title", >> "name": "Research Scientist" >> }, >> "k2": { >> "kind": "role", >> "name": "Project Leader" >> } >> } >> >> What should be an array of strings (e.g. “List<String> titles”) is instead an >> object of objects, where each nested object has meta-data and is given a >> unique property name thus requiring the implementer to manually map the >> nested objects. There are even more complicated examples, such as the >> “name” object where given, middle, and sur names can be intermingled in sub- >> objects. IMHO, JSContact makes the same mistake of jCard but in the opposite >> way: where jCard has arrays that should be objects, JSContact has objects >> that >> should be arrays. >> >> #2 Patch Objects >> >> JSContact has PatchObjects, which are a means of “patching” parts of >> JSContact >> with other parts of JSContact. The only example of it in the I-D is for use >> in >> postal address localization, which IMHO is an extremely overly-complicated >> approach to the problem. This mechanism is not simple for server >> implementers and will be very troublesome for client implementers. >> >> PatchObjects will also cause havoc with RDAP redaction, as far as I can see. >> Are >> the patches created before or after redaction processing? >> Are the patches themselves redactable? >> >> #3 JSContact Implementations and Scope >> >> I did a little hunting around for implementations of JSContact, and I could >> only >> find one. While that is the same number of jCard implementations I found, I >> would have hoped for many more in many different programming languages. >> As it stands, any implementer of JSContact for a server or a client will >> need to >> be intimate with the complexities of JSContact just as they have had to do >> with >> jCard. >> >> This is important because both jCard and JSContact can express contact >> information far in excess of what is found in the RDAP ecosystem, such as >> photos and birthdays and anniversaries. For a developer implementing a >> client, >> consulting the IANA RDAP extensions registry helps to understand the scope of >> the work necessary but that does not help with either jCard or JSContact. >> What >> of the many, many items in either does an RDAP client implementer not have >> to implement? There is no answer. >> >> Path-forward #A: SimpleContact >> >> Up until the WEIRDS wg was encouraged by the IETF to “eat its own dogfood”, >> contact information in RDAP looked like this (draft-02): >> >> "entityNames": [ "Joe Bob, Inc.", "Bobby Joe Shopping" ], "postalAddress" : >> [ >> "123 Maple Ave", >> "Suite 90001", >> "Vancouver", >> "BC", >> "12393" >> ], >> "emails" : [ "[email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>", "[email protected] >> <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>>" ], "phones" : >> { >> "office" : [ "1-958-555-4321", "1-958-555-4322" ], "fax" : [ >> "1-958-555-4323" ], >> "mobile" : [ "1-958-555-4324" ] }, >> >> Using experience from EPP, the ccTLDs and the RIRs we could build upon this >> and create a “simple contact” extension for RDAP. >> >> Path-forward #B: jCard and JSContact profiles >> >> RFC 9083 has this bit of text: “Many of the types of information that can be >> represented with jCard have little or no use in RDAP, such as birthdays, >> anniversaries, and gender.” As I asked above: what of the many, many items in >> either jCard or JSContact does an RDAP client implementer not have to >> implement? There is no answer. >> >> 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. >> >> Path-forward #C: Both #A and #B >> >> -andy _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
