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