> -----Original Message----- > From: regext <[email protected]> On Behalf Of Gould, James > Sent: Monday, January 9, 2023 12:08 PM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: [EXTERNAL] Re: [regext] RDAP queries based on redacted properties > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content is > safe. > > I'm getting a little confused, where the ability to redact a field like the > mandatory "uid" field in draft-ietf-calext-jscontact and indirectly in > draft-ietf- > regext-rdap-jscontact is needed for privacy reasons. It is up to server > policy > related to whether to include the "uid" field in the domain response, entity > query, and entity response, which should not be dictated by the protocol. > The > base specification or specifications need to be less strict on the > definition of a > field such as the "uid" field to support the use of those specifications > downstream. In this case, RDAP is the downstream protocol that needs to > support redaction of the "uid" field, since it's defined as being the same > as the > "handle" field of jCard. My recommendation is to make the "uid" a SHOULD or > MAY in draft-ietf-calext-jscontact that doesn't seem desired by CALEXT or > have > draft-ietf-regext-rdap-jscontact override it to make it optional in RDAP to > support the known redaction use case.
[SAH] If draft-ietf-calext-jscontact is a normative reference for draft-ietf-regext-rdap-jscontact, and the "uid" property is mandatory in draft-ietf-calext-jscontact, an override is going to be a problem. It'll make things difficult for any library that implements JSContact because the specs will be inconsistent. Has there been push-back from calext on the idea of making the uid OPTIONAL? Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
