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] 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. > >> 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. > > > >> 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. > > >> 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) In both those examples, all the types were "work". Are there any examples where "home" is used? 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? 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). > >> 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?". 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? 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. > >> 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. > >> 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. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
