Hi Andy,
please find me responses inline.
Il 06/07/2023 16:37, Andrew Newton ha scritto:
Response in-line:
On Thu, Jul 6, 2023 at 2:08 AM Mario Loffredo<mario.loffr...@iit.cnr.it> wrote:
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.
Is this the whitepaper?
https://www.centr.org/library/library/download/10478/7435/41.html
Are any CENTR registries or registrars publishing that information? I
am not a lawyer, but that would seem to run counter to GDPR.
The whitepaper also mentions the National ID of individuals. Are they
publishing that as well? I ask because that couldn't happen in the
United States, and we have some of the worst privacy laws in the
world.
If the wg wants to add them in, I suggest doing so under a proviso
that the information MUST be strictly published for non-public use.
[ML] If that information is collected, it doesn't necessarily mean that
it is publicly available.
It can simply be accessed by any allowed user.
What should be the usefulness of rdap-openid if RDAP responses couldn't
be provided based on user profiles ?
[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.
Good catch. I guess that answers that question.
[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 ?
It's the latter. We can add some clarifying text. The plural JSON
names are done purposefully for things that are arrays. But that's
just a style issue.
[ML] I guessed it was the latter. IMHO, the information and its
language-dependent version are two distinct things.
In this case, there is one only name in the native (default) language
and many translations of it in different languages.
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.
The text indicates that it is the same format, not the same purpose.
We can clarify that and add some more examples to make it clearer.
Think that specifying the default language in one place would be better
than repeating it in every object where it makes sense.
Why? That seems to be more work for the client.
[ML] We have different opinions about what it means "doing more work".
For example, I believe that having a apecific handling of
language-dependent alternatives for each object
takes more work than implementing a method that can process every
localizations including those related to extensions.
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 ?
What's the practical difference to a client? A client would use the
same display logic for implied preference order and no preference
order. We can add explicit preferences, but it seems unnecessary and
puts more work on the client.
[ML] If the logic was to search for the preferred item if any, the
response would be different. For example, in the case of a company
offering multiple phone numbers in order to be contacted, the effect on
the distribution of the phone calls is different if there is a preferred
number or no preferred number.
Anyway, if you think that using the array order is an unambiguous way to
represent preference or not, go that way.
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
(seehttps://rdap.cctld.kg/domain/nic.kg and
https://flexireg.net/moscow/rdap/domain/nic.moscow)
In both those examples, all the types were "work". Are there any
examples where "home" is used?
[ML] There some "home" occurrences in the examples of RFC 9083.
Also, I think there is a big difference between "home" and "private".
And if a home phone is private, why is it being published in RDAP?
[ML] e.g. because the owner gave the consent for publishing it or an
authority is legitimated to access it if it's stored.
That said, the examples you gave do indicate there is a need for
"textPhones" (or whatever "smsPhones" or whatever we might want to
call it).
[ML} Don't think it's an efficient modeling approach from the
extensibility perspective to replicate data structures to support
multiple phone features.
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 ?
I think that should be changed to "do you think that it might
reasonably be used in the future?".
[ML] The point is in what extent your data model is easily extensible
and resusable.
TZ maybe, but we'd need guidance on the ABNF.
KEY is much too nebulous to be useful. Or those car keys? SSH keys?
Bitcoin keys? What algorithms are used?
[ML] In JSContact, there is only one object representing a cryptographic
resource. If you think that it's not comprehensive enough, we are still
in time to further specify the values of the kind property.
TITLE is probably not useful. I've never seen anybody say they were a
Senior Vice President when getting a domain name or IP address.
Honestly, I wouldn't base my data model solely on the information
defined by EPP.
It is not. Please see the references in Section 1.
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.
In both examples you gave above, both fit easily into SimpleContact
structured postal addresses.
Thanks for providing an answer to the question of the need for
structured postal addresses.
[ML] Wouldn't say easily if you put everything that doesn't match the
western postal address scheme in an array. New version of JSContact spec
includes some examples about real postal addresses. You can test if you
loose information by representing those addresses with SimpleContact.
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.
The intent is to allow the specification of an email address where the
display name differs.
We can add some clarifying text.
[ML] Was talking about EAIs and their related ASCII versions.
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.
Please see Jasdip's response on this topic.
[ML] Think don't need to further reply on that. Don't want to appear too
polemical.
Best,
Mario
-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
