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. We left them in the draft but want the WG to guide here. > > > 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..." > > 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." > > 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. > > 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? 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. > > > 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? > > > 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? > > > 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. 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
