Hi Andy,
please find my comments below.
I added some examples of RDAP queries returning responses including
features that in my opinion are not fully matched by this specification.
It took very short time to me to discover those responses and I did it
by using only the information included in the bootstrap registries.
As a result, I can say that they are not corner cases and there might be
further jCard features that have not been considered.
For example, if you take a look at the "CENTR white paper on data
accuracy", you will realize that the are registries storing the date of
birth of registrants as individuals.
Data accuracy is a relevant topic for the European registries.
Registration data should be as detailed as possible to permit the
execution of consistency checks and identify fake data.
Il 05/07/2023 21:43, Andrew Newton ha scritto:
Mario,
Thanks for looking at it. My comments are in-line:
On Wed, Jul 5, 2023 at 2:42 PM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote:
Hi Andy,
thanks for this document. I can finally compare it with JSContact and
provide some feedback:
1) First, I'm happy to note that, with reference to the first draft
proposal included in
https://mailarchive.ietf.org/arch/msg/regext/56Nk70dpoxFOdlK2rw_QSiPlg9Q/,
some arrays of values have been turned into either objects or arrays of
objects and further information has been modeled. This is because
SimpleContact has become "more complex" to support additional features
not considered initially. In some cases, this specification is even
"more complex" than JSContact (e.g. in JSContact the name information is
represented through a single object instead of a collection). If I may,
by using your words, I would say that SimpleContact is making the same
mistake as JSContact about the use of arrays and objects.
The JSON style issue aside, we did note that structured names do not
appear to be used in RDAP. See the references in Section 1 of the
draft.
[ML] They are used (see for example
https://rdap.arin.net/registry/ip/199.0.0.0)
We left them in the draft but want the WG to guide here.
[ML] The point is that the property name "individualNames" is
misleading: do you mean that a contact can have more names or do you
mean that a contact has one only name and can have some translations ?
2) It seems to me that this specification doesn't ensure the full
backward compatibility with all of the jCard features currently used in
RDAP. Here in the following some of them:
a) some registries use the LANG property to set the default language
That's addressed in section 2: "There are two common, optional JSON
members of these child members: "lang" and "masked".The JSON member
"lang" is the same as that defined by RDAP..."
[ML] The LANG property in RFC6350 is the default contact language, hence
it is different from the "lang" attribute as defined in section 4.4. of
RFC 9083.
Otherwise, don't see how it is used in some jCard examples of RFC 9083.
Think that specifying the default language in one place would be better
than repeating it in every object where it makes sense.
b) some registries use the PREF parameter of TEL and EMAIL properties
(e.g., if I remeber well, APNIC represents the preference information in
email addresses)
Also addressed in section 2: "Most of the child members are arrays
allowing the expression of multiple variants of the same information.
The order in which items appear in these arrays denotes preference
order for the variants."
[ML] This preference information is not the same as that defined by RFC
6350 since it assumes that every collection is sorted by preference.
On the contrary, RFC 6350 admits cases where there is no preference.
Hence, RFC 6350 (and JSContact) is more flexible here.
For example, do you mean that in the voicePhones example the preferred
phone number to be used is the first one ?
c) some registries use the TEL-TYPE parameter (e.g. to represent work
phone numbers)
Those would be "voicePhones" in SimpleContact. See Section 2.5.
[ML] Here again the RFC6350 (and JSContact) is more flexible since you
are allowed to specify if a phone number is private or is used for work
(see https://rdap.cctld.kg/domain/nic.kg and
https://flexireg.net/moscow/rdap/domain/nic.moscow)
d) some further jCard features included in RFC 9083 examples don't find
counterparts in this specification (e.g. KEY, TZ, TITLE properties).
Do you plan to match such features ?
If people use them, then yes. Are they used by DNRs or RIRs today?
[ML] I see only two alternatives:
1) The example in RFC 9083 is impractical then it should be corrected
2) The example in RFC 9083 is practical then a contact representation in
RDAP should consider those features
Another answer could be: do you think that it might be used in the future ?
Honestly, I wouldn't base my data model solely on the information
defined by EPP.
WRT to TZ, we'd also need some guidance on how to reference that
standard. As far as I can tell, there is no TZDB ABNF but I'm far from
an expert on it.
[ML] There is a Time Zone Database mantained by IANA
3) The EPP postal address scheme is unfit to represent some items used
in non western postal address schemes (such as district, sub-district.
block). This specification requires a server to include in
"deliveryLines" the addtional information but such additional items
cannot be clearly identified. With regard to this aspect, this
specification doesn't address the problem of representing postal
addresses other than western ones. The style is different but the
information is exactly the same as jCard.
Correct, it is influenced by jCard and so far that seems to be working.
That said, if you have some suggestions I'd be open to them. I did look at
how PIDF-LO represented these things but it seems to punt on it.
It also remains to be seen how much structure of postal addresses is
actually collected by DNRs and RIRs.
Can you provide any DNR or RIR examples where SimpleContact does not work?
[ML] If thus far RDAP providers have had no alternative to fit their
postal addresses into a scheme other than the jCard, it's quite obvious
that you will not find examples in RDAP.
But you can find some examples where the street address component of the
ADR property is represented as an array (see
https://rdap.afilias-srs.net/rdap/asia/domain/nic.asia or
https://rdap.nic.fr/domain/nic.fr). Those examples demonstrate that
information about postal address could be structured in a way permitting
the clear identification of those additional address components.
The point is if you plain to match those components to make your data
model more structured, more flexible, more comprehensive and less
unmbiguos.
4) About the localizations, it seems to me that this specification
assumes that one contact can include at most one kind of information and
one related localization at most, I mean one internationalized postal
address and a localized version, one ASCII email address and its UTF-8
version. Otherwise, I don't see how it would be possible to link
together multiple language-dependent alternatives. For example, how
would it be possible to link two ASCII emails with their related UTF-8
versions ?
Can you provide a concrete example? I don't understand the issue you
are describing.
Is linkage not implied by virtue that they appear in the same entity?
[ML] It is not implied if you admit the case where you have more than
one email address each one in both ASCII and UTF-8 version.
Is this a corner case ? It looks to me more likely in the RDAP context
than representing honorifics and titles in names.
5) I'm very curious to know the WG reaction about the use of "noJCard"
extension. AFAIK, providing an alternative represention along with
jCard in an RDAP response has not been considered an issue so far even
in case of handling large amounts of data. Most of us (not me) have
considered too complex for both clients and servers to imlement the
negotiation of the contact representation to be returned in the
response. In addition, in this case, the negotiation is made through
two extension identifiers while in rdap-jscontact setting the jscard
parameter to 1/true means that jCard is not returned.
For most lookups, returning both will not matter much. However, for
searches yielding many more than one result it could be a definite
bandwidth savings.
[ML] Don't tell me that. I'm perfectly aware of it. I've always had a
position consistent with RFC 8977 and RFC 8982.
You cannot support RDAP features to make the search response payloads
more sustainable and, at the same time, allowing the server to provide
the same information twice for each contact returned.
Best,
Mario
The implementation would most likely be up to server policy on the server side.
-andy
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
