> Le 11 janv. 2023 à 12:43, Gould, James <jgould=40verisign....@dmarc.ietf.org> > a écrit : > > 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.
My 2 cents. an object shall have a mandatory unique identifier. I think we are going way too far by removing a unique (random) object identifier for the purpose of privacy. A UID/UUID does not provide any privacy related info. I’m aware of the cross references, but I just think we are going way too far. I would vote for keeping the UID as mandatory, since for an implementer perspective, I can keep this object and its UID, put it in a database and know when I have an updated version of that object because the UID is unique and mandatory. Without UID, all objects are different, and this is no fun to correlate: I would potentially have multiple copies of the same object without being able to flush them out, unless a do a full deep comparison, which does not make any sense. My 2 cents Regards, Marc. > > -- > > 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
