Hi Mario, On 24.07.25 14:24, Mario Loffredo wrote:
PK> OK. Clear. Yes I indeed follow the EPP model or rather general model supported by most/all? DNRs. I see full is required and components optional, so we are good.Hi Pawel, please find my comments inline prefixed with [ML]. Il 22/07/2025 18:23, Pawel Kowalik ha scritto:[ML] It seems to me that you're referring to the EPP contact data model. However, while testing the implementation of an RDAP response validator, I discovered that some servers, particularly those in RIRs, only use the different format than the one used in EPP, or both.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 NameFor example, the response to the lookup query https://rdap.arin.net/registry/ip/199.0.0.0 returns both jCard n and fn elements.In this case, I assumed that the property name was available and that the full name had been derived. Obviously, the structured name makes sense only for individuals.
PK> OK, this would be a friction for the clients to support both, so unless RIRs say they also have structured data we can't do any better. Thanks for clarification.[ML] Viceversa, here in the following examples where the postal address is represented only as an unstructured text.full Address -> we have components of Addresshttps://rdap.arin.net/registry/ip/199.0.0.0 (again) https://rdap.apnic.net/ip/133.0.0.0 https://rdap.db.ripe.net/ip/193.0.0.25In these cases, I assumed that either only the unstructured postal address was available or mayve RIRs share the policy to display the full address (@Tom, @Jasdip you can shed a light here).The above cases made me think that both formats should be allowed.
[ML] The draft does not propose replacing existing entries for jCard elements, but rather adding new entries for JSContact properties.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.Section 5 of RFC9536 allows a reverse search property to have multiple registered mappings.
PK> OK, thanks.
PK> Indeed, again I refer to DNS data model in a wider sense, however with "Additional Email Address Extension" this would also apply to EPP.[ML] As opposed to the answer above, it seems to me that you are not referring to the EPP contact data model.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"...
The purpose to use specific map keys is multiple:1) improve interoperability: almost all DNRs adopt the EPP contact data model so they handle a postal address, a email address, a voice number, a fax number. At most, they handle a language-dependent variant for some specific properties which in JSContact are represented via the localizations property.2) simplify implementation: when keys are predefined, a JSON map can be deserialized into an object. Any unknown or additional members of a JSON map can be deserialized into a map member. For example, using the Jackson library annotations @JsonAnyGetter and @JsonAnySetter, the JSON "phones" map can be deserialized into the following "phones" object :[...]3) speed up the retrieval: in the case of the example above, to get a fax number you don't have to iterate on the map items to look for the one including the "fax" feature.
PK> Yes, the intentions are very clear to me.
PK> That's ok, as long as all keys follow the same schema, not that one is "special" and rest is on a side.That said, have no objection to removing the type from the additional keys, but I would keep the predefined keys.
PK> Almost any "human readable" keys would create such impression. Even an array would. This is not my point however.After all, using only numbers as keys would still give the impression of sorting the entries by preference.
In contrast, JSContact uses maps to represent unordered collections, and preference order is passed via the pref property.To avoid misunderstandings, I propose adding some text clarifying that the order of appearance of the map keys doesn't correspond to a preference order.Would it be fine with you?
PK> Yes, such text should be helpful.
There is an interesting aspect of it which I think the draft should cover:[ML] As I mentioned above, AFAIK in the large majority of cases, there is only one piece of information for each type. So there is no problem sorting the same information in a different order.- 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.
PK> If there is one, there is no issue at all. Correct.
PK> Quite simple, the implementation has to take care to order the entries always the same way (in SQL terms have always defined "order by") to maintain the same order. The draft must be then very clear about this implementation requirement.Nor I can imagine why a server should display the entries of a map in a different order for two subsequent queries.
PK> Robert pointed me to 1.4.1 of RFC9553 where it is stated, that the map keys MUST be preserved across multiple versions of the JSContact object. I interpret 2 consecutive responses to be "versions of the same object.On the other hand, I admit that map entries can change: they can be removed or replaced with other values (I'd argue that even in these cases maps work better than arrays because order matters in arrays not maps). However, using the predefined keys can still have advantages, e.g. if the fax number is removed, it's easy to discover that the "fax" key is missing and no fax number is available.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.[ML] Having a stable order of values is not important. Registration data can be updated, so it's obvious that the property values of a JSContact representation in RDAP can change over time.
What really matters for both clients and servers is the stability of the propery names i.e. the keys.PK> if you interpret it the way that "under this key the client will hit some data of a type" then I agree. If the promise would be, following how i read RFC9553, that under same key you get the same data, then this won't be fulfilled.
PK> This was a minor remark for the situation that such gaps would have been created by "sticky" keys. No action needed.[ML] Does it match a real-world use case ? It doesn't seem so to me. The RDAP response is a snapshot of the information currenltly stored in the registriy database.Finally, having gaps in a theoretically continuous numbering has a minor data protection leak element as it reveals that some item was removed.Don't think either servers or clients need to worry about preserving history.
There is a potential technical solution that does not have all those issues, where keys would be hash values over the content of the object or it's unique key. None of these would produce foreseeable keys though, so client would have to always iterate.
By no means I propose to go this way, so don't get me wrong. Just the opposite, I want JSContact usage in RDAP to be as straightforward as possible. It should not mislead clients by unsaid assumptions either side may make.
What I would like to see in the draft is clarity about properties and promises which usage of this structure gives to the clients as well as requirements that the server generating such payload must fulfil. 1.4.1 of RFC9553 must be addressed in a way as well, as this is not a SHOULD but MUST.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
