Mario, I'm assuming that JSContact will define an expected format for the "uid" field that we must comply with in RDAP, which is not needed for RDAPs use case. Use of redaction by empty value would not be compliant with the potential format language. The difference between jCard and JSContact is that jCard was already an RFC when RDAP was being created, where JSContact is currently an Internet Draft. You are aware of the need to redact the "uid" field for the RDAP use case, so why not make the "uid" optional in JSContact to make it meet the broader use case of RDAP with some potential caveats (e.g., the "uid" MUST be set when there is the need for discovering, comparing, or synchronizing contact cards)? RDAP doesn't have those needs, so the inclusion of the "uid" can be optional and used where it makes sense, such as returning in an entity query response. The "uid" could match the "handle" and be redacted in the domain query response.
-- 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 1/11/23, 12:30 PM, "Mario Loffredo" <mario.loffr...@iit.cnr.it> wrote: 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://secure-web.cisco.com/1B6D4pyxmKDwpO1gDg8JCbAyyVnB2BvaZ3JTJ2vkSu_vvQpsRQ6yGI7r7rV6ALrqDDaNK22Tke5DGTxnefzXpN6Kzy7siSan8535YNrq8wT7WnJJIS3ofhq4YG3Oeh0j_1eJXco8RFN_saliLVB90qsi9xRM1kthbq1PXvmQp3MYHvtamKSW-yBvqfFlZhjNTe3bpL-pdA1uQWOh0jxoYKH4Fj55XEXH-t9-lUHa8mP8FVp0SgeB-KUeIT4t-XR1tPVAg8_LqfmWf9dgNKYnYoot-KZNZ8L47x_bOp0u92mc/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
