HI James,
please find my comments below.
Il 10/01/2023 17:33, Gould, James ha scritto:
Mario,
This is the disadvantage of leveraging an existing set of contact drafts / RFCs to satisfy the
needs for contacts and entities in RDAP, whether it's jCard / vCard or JSContact. The contact
drafts / RFCs meet similar requirements but not the same requirements. The "uid" field
of JSContact is a simple example of where it makes sense for the JSContact requirements to have a
mandatory identifier that can be used to reference associations, but it doesn't make sense for RDAP
where there is already an identifier represented by the "handle" jCard field and the
contact ROID in EPP that needs to support redaction. This means that it can't be made mandatory
for RDAP.
[ML] I don't see much dfifference in using jCard rather than JSContact
with respect to this aspect.
RFC6350 states that FN is required because FN represents the vCard
identifier, therefore no vCard with an empty FN should exist.
Nonetheless, having considered mandatory the JSON member instead of the
JSON value, for convenience we admit the empty string for the jCard fn
property in RDAP but this wouldn't be indeed correct.
We can do the same with JSContact. JSContact requires that uid must be
not null instead of the fullName (the JSContact counterpart of FN in
vCard) and, being the free-text format also allowed for uid, I deem that
the emptyValue redaction method could be used as well.
If JSContact defines a new required identifier in the form of a UUID then the
provisioning system needs to generate a new identifier just for displaying it
in RDAP via JSContact or the RDAP server needs to create a useless random
identifier with every response. .
[ML] The alternatives I have proposed (i.e. name-based UUIDs and random
UUIDs) don't require to store the uid value. As you said, it can be
simply generated at every response.
This doesn't seem to me a big price to pay compared to defining a new
contact representation from scratch.
Guess this was the philosophy that led to the adoption of jCard. The big
difference compared to JSContact is that unfortunately jCard is not a
data model.
You and Robert as JSContact co-authors need to consider the broader use of the draft for
defining a required field. Why not make the JSContact draft more flexible to the broader
set of uses and provide guidance for the known or the primary use case? I believe the
JSContact "uid" field needs to be made optional (SHOULD would suffice) to cover
both the primary use case of JSContact and the RDAP use case of JSContact.
[ML] SImilarly to vCard/jCard, the primary use of JSContact is to
represent contact card information. In that context, having an
identifier that is not based on the free-text format (like FN in vCard)
is very helpful in many cases such as discovering or comparing or
synchronizing contact cards. This is so true that Calext has followed
the same approach in defining the identifier for the JSContact sibling,
namely JSCalendar.
If that can't be done, then JSContact may be the wrong JSON draft to use for
RDAP contacts and entities.
[ML] Obviously, I disagree :-). As generic contact card representations,
both jCard and JSContact are slightly adjusted to be used in RDAP. Both
of them represent a superset of the contact information normally used in
RDAP. But JSContact is more manageable than jCard . Therefore, it
doesn't make sense to me to define an ad-hoc representation if the
mandatory constraint of the uid property can be worked around somehow.
Best,
Mario
Thanks,
--
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
