Hi Mario,Thanks for this update. The use of profiles would really make use of JSContact more feasible.
After reviewing the document I have few remarks, as indicated in today's IETF 123 WG session:
1) Some fields in the profile seems duplicated to other fields and I am not convinced we need them at all:
components Name -> we have full Name full Address -> we have components of AddressI think the list of available values for "kind" field of AddressComponent or "features" of Phone shall be limited by the profile and I will forward this feedback to the calsify WG, as I see this feature is now missing in the profiles draft.
2) 6.3. RDAP Reverse Search Mapping RegistryThe draft is practically now proposing to replace the IANA entries, which actually make Property Path not covering the current expression of the contact as jCard.
I think either the proposed entries have to support both or list both in IANA. Other approach would be not to update IANA until the experiment is concluded.
3) 3.1.12. Map KeysWhile I appreciate the predictability of labels in the map keys I am concerned about the choices made there.
The choice to have one special item of the map, like "email" and then "the rest" with a different notation "emails-1", "emails-2" etc. gives an impression that there is "primary" vs. "secondary" relation between the entries which might not exist or be even not wanted. I think having a uniform lists starting from 1, so just "email-1", "email-2" etc. The first item can be then always referred to using stable path $.emails.email-1.
One can argue, whether "<type>-" prefix is needed at all. Apart from "phones" map, all other carry the same kind of data, which could be also addressed by the numbers "1", "2", "3"...
There is an interesting aspect of it which I think the draft should cover:- whether these keys are stable? - meaning if "emails": { "1": "[email protected]", "2": "[email protected]" } can become "emails": { "1": "[email protected]", "2": "[email protected]" } on a consecutive request. Further, if the assumption would be that the keys won't change, whether after removing "[email protected]" would "[email protected]" stay at key "2" or then move to key "1".
Having these keys being not stable would technically make them having exactly same properties as an array, just with added complexity. This is only a side note, as I understand this is a design decision of JSContact, not the implementation decision for RDAP.
Additional note to that point is that some registry systems do not order these items in a deterministic way, so having a stable order may render hard to implement.
Finally, having gaps in a theoretically continuous numbering has a minor data protection leak element as it reveals that some item was removed.
Kind Regards, Pawel On 01.07.25 16:33, Mario Loffredo wrote:
Hi,this version doesn't include support for the uid property as it refers to JSContact v2.0 which made uid optional (draft-ietf-calext-jscontact-uid <https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact-uid/>).Therefore, there is no longer any concern about the uid property being mandatory in RDAP.It also includes a section about registering the "rdap" JSContact profile (draft-ietf-calext-jscontact-profiles <https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact-profiles/>).Any feedback is appreciated. Best, Mario -------- Messaggio Inoltrato -------- Oggetto: [regext] I-D Action: draft-ietf-regext-rdap-jscontact-22.txt Data: Tue, 01 Jul 2025 07:14:48 -0700 Mittente: [email protected] Rispondi-a: [email protected] A: [email protected] CC: [email protected]Internet-Draft draft-ietf-regext-rdap-jscontact-22.txt is now available. It is a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON ResponsesAuthors: Mario Loffredo Gavin Brown Name: draft-ietf-regext-rdap-jscontact-22.txt Pages: 32 Dates: 2025-07-01 Abstract: This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact-22 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-jscontact-22 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list [email protected] To unsubscribe send an email [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
