Hi Pawel,
again my comments inline prefixed with [ML2]
Il 24/07/2025 18:09, Pawel Kowalik ha scritto:
Hi Mario,
On 24.07.25 14:24, Mario Loffredo wrote:
Hi Pawel,
please find my comments inline prefixed with [ML].
Il 22/07/2025 18:23, Pawel Kowalik ha scritto:
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
[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.
For 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. 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.
[ML2] Agreed. I would keep the optional capability to represent thr name
components for individuals. It could be helpful for future developments
where an identity verification via an eID system could at least allow to
identifiy the first name and the surname.
full Address -> we have components of Address
[ML] Viceversa, here in the following examples where the postal
address is represented only as an unstructured text.
https://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.25
In 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.
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.
[ML2] Agreed too. The way the full address is formatted in thso examples
makes me think that the address components are stored in RIRs' databases
but it's weird that they are not displayed.
If we realized that the full address is always a transient property, we
could use only the address components.
2) 6.3. RDAP Reverse Search Mapping Registry
The 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.
[ML] The draft does not propose replacing existing entries for jCard
elements, but rather adding new entries for JSContact properties.
Section 5 of RFC9536 allows a reverse search property to have
multiple registered mappings.
PK> OK, thanks.
3) 3.1.12. Map Keys
While 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"...
[ML] As opposed to the answer above, it seems to me that you are not
referring to the EPP contact data model.
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.
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.
That said, have no objection to removing the type from the additional
keys, but I would keep the predefined keys.
PK> That's ok, as long as all keys follow the same schema, not that
one is "special" and rest is on a side.
After all, using only numbers as keys would still give the impression
of sorting the entries by preference.
PK> Almost any "human readable" keys would create such impression.
Even an array would. This is not my point however.
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.
[ML2] OK. I'll remove the type from the additional keys and add that text.
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.
[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.
PK> If there is one, there is no issue at all. Correct.
Nor I can imagine why a server should display the entries of a map in
a different order for two subsequent queries.
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.
[ML2] Depending on the sort conditions, the order couldn't always be the
same if the data were changed between two queries.
The best I can do here is add some text indicating that, in the absence
of updates, the order of the additional keys SHOULD always be the same.
Is that OK?
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.
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.
[ML2] The primary purpose of this statement was to preserve keys during
round-trip conversions, i.e., JSContact->vCard->JSContact.
We've extended vCard to include JSContact key information, so that when
a vCard instance resulting from a conversion from a JSContact card needs
to be converted back to a JSContact, the resulting JSContact card will
be identical to the original.
In the RDAP context, this means that you should always use the same keys
in the RDAP responses.
This is precisely the goal of the keys defined in the draft.
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.
[ML2] Agreed about the first interpretation.
Finally, having gaps in a theoretically continuous numbering has a
minor data protection leak element as it reveals that some item was
removed.
[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.
Don't think either servers or clients need to worry about preserving
history.
PK> This was a minor remark for the situation that such gaps would
have been created by "sticky" keys. No action needed.
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.
[ML2] I think the proposed clarifications will help avoid misunderstandings.
Best,
Mario
Kind Regards,
Pawel
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
