Hi Andy, I made the original proposal to replace jCard, with a straight mapping of RFC5733 contact objects into JSON, back in 2019:
https://mailarchive.ietf.org/arch/msg/regext/bZA9yGAdy2fPaDxiMuMr5CE-z74/ A certain Mr Newton (perhaps you know him) raised the point that this would exclude non-EPP based implementers such as RIRs. Shortly afterwards, the first JSContact draft was published, which I suggested could be the solution, which is why it was subsequently adopted. It must be said that JSContact evolved quite a bit since the first draft, and many of the features which made it attractive as a developer have been lost as it has been developed. Speaking as Mario's largely silent co-author, I am not wedded to JSContact, I just want to replace jCard with a sane way of representing contact data in RDAP responses. JSContact seemed like it was the most likely thing to achieve that back then, but it may not be now. G. On Wed, 07 June 2023 18:26 UTC, Andrew Newton <a...@hxr.us> wrote: > 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", "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 https://www.ietf.org/mailman/listinfo/regext
