Mario, I don't see any need to add a dependency between draft-ietf-regext-rdap-jscontact and draft-ietf-regext-rdap-redacted, but this does add an interesting case for draft-ietf-regext-rdap-redacted with redacting a required JSON member. Do you see the requirement to be able to redact the required "uid" JSContact property? If there is the need to redact it, then wouldn't that make the case for it not to be defined as mandatory in draft-ietf-calext-jscontact? I'm not sure whether providing an empty value via the Redaction by Empty Value Method is any better than simply removing it via the Redaction by Removal Method. We would need to first determine whether there is the need to cover the case of redacting a required JSON member in draft-ietf-regext-rdap-redacted and if so how best to handle it.
Thanks, -- 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 12/14/22, 3:28 AM, "regext on behalf of Mario Loffredo" <regext-boun...@ietf.org on behalf of mario.loffr...@iit.cnr.it> wrote: Hi Andy, again my comments below Il 13/12/2022 19:38, Andrew Newton ha scritto: > On Tue, Dec 13, 2022 at 12:12 PM Mario Loffredo > <mario.loffr...@iit.cnr.it> wrote: >>>> The entity lookup URL MUST always be used regardless of the query generating the response including the contact card. >>>> >>>> Does it work for you? >>> JSContact says that it SHOULD be a URN in the uuid space and MAY be a >>> URI. Why deviate from that? Can it not be a URN in the UUID namespace? >> [ML] Didn't want to ask the implementers for an additional effort. >> Excluding the case that the UUID is created once and stored, to keep the >> same UUID across different responses including the same contact, the only >> >> alternative is to generate it from the handle value through an hash >> function. As a Java programmer, I know it is possible and provided by >> some libraries. Honestly, can't say the same for other languages. >> >> Since an URI is allowed, it seemed to me better to propose an univerally >> unique URI that could be easily generated. > UUIDs are pretty standard things, and I wouldn't be surprized if > implementers let their database do the work anyway as many DBs have > functions to generate them. But implementation considerations are a > good thing. > > Perhaps follow the guidance in the JSContact draft... SHOULD be a UUID > URN, MAY be a URI where the URI is the entity URL. > > The use of JSContact is supposed to bring other benefits because it is > a standard used in other places. The further we stray the further > those benefits erode. Otherwise we should just use our contact model > such as that found in EPP and the original RDAP drafts. [ML] Your suggestion about how to rephrase the sentence sounds good to me. I'll change the text accordingly and the examples by using URNs in the UUID namespace. > >>>> Nevertheless, should I add text stating that, being uid mandatory, it MUST be redacted by the emptyValue redaction method as defined in draft-ietf-regext-rdap-redacted ? >>> That seems to work, but should this go in the redacted draft instead of here? >> [ML] Think this document is the right place. The redacted draft defines >> the redaction methods and this document defines an extension that makes >> use of one those methods. > The issue is that you are now entangling the two docs in the > publication process. [ML] Maybe I didn't catch the exact meaning of this sentence but I think just the opposite. In addition to the conceptual reasons, making the rdap-redacted to reference rdap-jscontact would result in a circular dependency between the two documents. @James Gould: Could you please give your opinion on this point? Mario > > -andy -- 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/1R6F0cw8iaPKawZdvhjH8oXOrzcTRGz_i3kAgn6QFYPgLMII6CXaRM0bNeQgFBTpwLpjinReLXu6Fco9FnScAC6QMQHb97TNzzBQNHckO_MQBmUIBJcMZs-MAbmsGZHNcIRfBHS2Z38fuQNejf52uHAqBRe6AGlD9y-MnNRsitPq-kdV0PMDHQaJTkr1uReSbOVntVN5f59VLgALemXWuDZWlSn1_I8ItIw8_AElT1fW7pSV8PS9WQ62SJBZLGTDSrdITkdmr8Zu5xIl9OlO39Vt9jUVUSrqyTf8tyDFyx3WFz-S6g-thcxutgRMLX_hc/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1Gq63KU6_2l6TYOjtCI1P38iZYDkOuaMxaGzaw3YBei5u83mfpncX97lIeKg2uPoPlDvpVzv-3fst1RTLlBHe6pVG4esp9ooMtMfRVlHDsXeeG7nlYE9Hl2tGHd2tLyr-5cm0gkPoj6e9MLs6Zf96Aez8S8JnqpwF-updzJukq-VNYMChSR82Fa8eHO10Y0rPzpNenbq0VYtd2ntDGnwaN0SmkZknRtfW463MXwDM65Tm8lGzf2Y5bWoVm3ueQWa4kAF8uIos3Btd_eAheHHeVOprpJgHxXGlBR-BQrhjiFtx66D-MAanm_SbD3F-z0Zl/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
