Hi Pawel,
please find my comments inline prefixed with [ML].
Il 22/07/2025 18:23, Pawel Kowalik ha scritto:
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
[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.
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.
I 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.
[ML] Robert have already replied that we'll include this feature in the
profiles draft.
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.
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.
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 :
{
Phone voice;
Phone fax;
Map<String,Phone> others;
@JsonAnyGetter
public Map<String,Phone> getOthers() { return others; }
@JsonAySetter
public void setOther(String key, Phone value) {
if (others == null) others = new HashMap<>();
others.putIfAbsent(key,value);
}
}
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.
That said, have no objection to removing the type from the additional
keys, but I would keep the predefined keys.
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?
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.
Nor I can imagine why a server should display the entries of a map in a
different order for two subsequent queries.
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.
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.
Best,
Mario
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 Responses
Authors: 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]
--
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]
