-----Original Message-----
From: regext <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>
<mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>>> On Behalf Of Gould,
James
Sent: Thursday, June 8, 2023 8:14 AM
To: a...@hxr.us <mailto:a...@hxr.us> <mailto:a...@hxr.us <mailto:a...@hxr.us>>; regext@ietf.org
<mailto:regext@ietf.org> <mailto:regext@ietf.org <mailto:regext@ietf.org>>
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
jgo...@verisign.com <mailto:jgo...@verisign.com> <mailto:jgo...@verisign.com
<mailto:jgo...@verisign.com>> <applewebdata://13890C55-AAE8-4BF3-A6CE-
B4BA42740803/jgo...@verisign.com <mailto:jgo...@verisign.com> <mailto:jgo...@verisign.com
<mailto:jgo...@verisign.com>>>
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-
boun...@ietf.org <mailto:boun...@ietf.org> <mailto:boun...@ietf.org <mailto:boun...@ietf.org>>
<mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> <mailto:regext-boun...@ietf.org
<mailto:regext-boun...@ietf.org>>> on behalf of a...@hxr.us <mailto:a...@hxr.us> <mailto:a...@hxr.us
<mailto:a...@hxr.us>>
<mailto:a...@hxr.us <mailto:a...@hxr.us> <mailto: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> <mailto:j...@bob.com <mailto:j...@bob.com>> <mailto:j...@bob.com
<mailto:j...@bob.com> <mailto:j...@bob.com <mailto:j...@bob.com>>>", "b...@joe.com <mailto:b...@joe.com>
<mailto:b...@joe.com <mailto:b...@joe.com>>
<mailto:b...@joe.com <mailto:b...@joe.com> <mailto: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
