Hi Andy,
thanks for sharing your thoughts about JSContact.
Please find my comments below.
Il 07/06/2023 20:26, Andrew Newton ha scritto:
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.
[ML] Collections of objects in JSContact are mainly represented as maps
because:
- first, as opposed to arrays, an entry can be got by key;
- in addition, when a set of keys is fixed in a specific context , a
JSON map can be deserialized into an object where the keys are property
names;
- finally, instead of the array items, map entries can be easily
pointed through JSONPointer/JSONPath expressions without knowing their
position in the map.
Moreover, objects have been used in place of simple data types to match
jCard elements and because they are more open to extensions. Some of the
object members appear meaningless in the RDAP context but are meaningful
elsewhere.
For example, with regard to the name information, the authors are now
approaching how to represent information about pronunciation. For sure,
this is a kind of information that will not be used in RDAP but will be
used by other applications.
In that perspective, your conclusion that "JSContact makes the same
mistake of jCard but in the opposite way" looks biased to me as it
starts from considering which contact data are just needed in RDAP
rather than to represent a generic contact. Would also like to outline
that no feedback about the overuse of objects have been raised from both
CalExt and IESG.
Surely, RDAP makes use of a subset of JSContact; nevertheless, in the
future, it might benefit from a contact data model which takes into
account more information and facilitates extensions by design.
#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.
[ML] Have implemented PatchObjects and it did not seem to me so hard to
deal with.
For the user, it's less straightforward than repeating both language and
alt information in each object that can have a language-dependent
alternative but it's less elegant conceptually and, what it is worse,
less extensible and less reusable.
Having a single point in the spec where you can include a
language-dependent alternative about any vaue/object prevents from both
adding the language and lang properties in any type, even when it looks
unnecessary, and updating the spec afterwards to add the language
information whereas it was not considered at first.
PatchObjects will also cause havoc with RDAP redaction, as far as I
can see. Are the patches created before or after redaction processing?
[ML] Sorry but don't catch this. If the unredacted version includes the
language-dependent information, they should be created before redaction.
Are the patches themselves redactable?
[ML] Why not ? They are redactable like any other value/object in RDAP.
#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.
[ML] Many implementations of both JSContact and jCard are proprietary.
Robert Stepanek is working on FastMail implementation of JSContact.
At present, only my implementation in Java is public but this doesn't
mean that there will not be other implementations available written in
any language soon, especially when the specification will be published
as RFC.
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.
[ML] Think the two complexities are not comparable.
jCard is inherently hard to process since it's not a data model.
JSContact is a data model hence it's absolutely straightforward in
serialization/deserialization from/to objects.
For example, one can easily derive his own implementation from the
outcome of a JSON-POJO converter available on the web.
In addition, JSContact complexity can vary depending on the set of
implemented features. I mean, EPP contacts can be easily either
converted to or directly represented through JSContact.
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.
[ML] Think this is a peculiarity of each abstraction. You can always
find inside something that you will hardly use but will be used by
someone else.
Even the RDAP data model includes information that exceeds what a
registry may need e.g. a generic DNR doesn't handle both ip and autnum
objects.
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.
[ML] IMO, the answer is simple: all of those he doesn't need.
This is a process that a developer normally does when he imports a
library into his project. He re-uses only the features he is interested,
he doesn't need to know all the features.
To guide implementers in finding JSContact counterparts of jCard
elements commonly used in RDAP, an appendix has been included in
rdap-jscontact.
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.
[ML] Would expect that SimpleContact will not based on positions like
in the example.
Obviously, I wouldn't support this proposal but I'm ready to drop
rdap-jscontact any time if the WG agrees about it.
I do believe it could result in a waste of time because I imagine that,
in the end, SimpleContact will not be so different from the JSContact
subset currently used in 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.
[ML] Don't wanna sound polemic but it's the first time I hear that the
concern is on what shouldn't be implemented instead of what should be :-))
Especially in handling JSON contents where you are allowed to omit the
handling of those properties that you want to ignore.
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.
[ML] If needed, I would support this proposal.
Path-forward #C: Both #A and #B
[ML] Does it mean that three contact representations (or two of them)
could be inclued in an RDAP response at the same time ?
If so, it doesn't make sense to me that server includes in the response
two (or more) representations of the same information (regardless they
are object-oriented or not) .
Best,
Mario
-andy
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
