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 jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/7/23, 2:26 PM, "regext on behalf of Andrew Newton" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of a...@hxr.us <mailto:a...@hxr.us>> 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" : [ "j...@bob.com <mailto:j...@bob.com>", "b...@joe.com <mailto:b...@joe.com>" ], "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 regext@ietf.org <mailto:regext@ietf.org> https://secure-web.cisco.com/1r4Wi1-NPZBDqwpyLN6BxTpMoPRLa8GfwJ0j1gqmlklT5Ok3AjIAaFP3TjMCZ5ao98ZKUJ1hKPGL1sxyv6NdmSgCCyD-7Z9SYuGOOLELVXwGcPY0AYQDIeEIyiwSnr9VIir2A2BTkgn6fpDWDJWGlWL7j9oFoH4vmwJ_VYuEaJlsr1iX72WbrV_0Ya8DIvSfDfISv_7NpvKNAlayyyCWXILPieLtSebHrY7lOiODr2ZLlStWZpV9XGXawNWfvF_5cLg6lfsRRXO_EKDXLVEr_Uurc9Zdif8Ge7aqcVHVETkI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1r4Wi1-NPZBDqwpyLN6BxTpMoPRLa8GfwJ0j1gqmlklT5Ok3AjIAaFP3TjMCZ5ao98ZKUJ1hKPGL1sxyv6NdmSgCCyD-7Z9SYuGOOLELVXwGcPY0AYQDIeEIyiwSnr9VIir2A2BTkgn6fpDWDJWGlWL7j9oFoH4vmwJ_VYuEaJlsr1iX72WbrV_0Ya8DIvSfDfISv_7NpvKNAlayyyCWXILPieLtSebHrY7lOiODr2ZLlStWZpV9XGXawNWfvF_5cLg6lfsRRXO_EKDXLVEr_Uurc9Zdif8Ge7aqcVHVETkI/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
