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 On 6/8/23, 8:52 AM, "regext on behalf of Hollenbeck, Scott" <[email protected] <mailto:[email protected]> on behalf of [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]>> On > Behalf Of Gould, James > Sent: Thursday, June 8, 2023 8:14 AM > To: [email protected] <mailto:[email protected]>; [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]> > <applewebdata://13890C55-AAE8-4BF3-A6CE- > B4BA42740803/[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]>> on behalf of [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]>>", "[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] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > 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 [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext> _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
