On Fri, Dec 8, 2023 at 3:57 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote: > > [ML] I would prefer "only express the items which are more likely used in > RDAP". After all, SimpleContact is not an RFC and, as such, could be subject > to changes resulting from the WG discussion. > > In this respect, have still retained the use of JSContact name components to > represent structured names. > > Apart from it and the language property, this version doesn't include extra > information.
I am good with this compromise, however my memory of the IETF 117 session was that items such as structured names were not desired. > > - clarify the use of 5733's "sp" (examples suggest it is a region > code, but it is a string) > > [ML] Don't think that we need to further clarify this. Appendix A already > clarifies that the region JSContact address component corresponds to the > region VCard ADR component. > Hence, the region JSContact address component is a string. I should have been clearer in my request. I don't think normative text is needed, but rather some informative text to remind the reader of this as the 5733 example shows what can easily be mistaken as a region code. > > - define RFC 8605 CONTACT-URI is a JSContact link of type "contact" > > [ML] Done. > > - more specificity of the 5733 int/loc mapping (use of und-Latn and > some clarity around the keys). > > [ML] Can you please elaborate this by providing some examples ? The idea is to specify 5733 "int" data as und-Latn. Yes, I'll work up some examples and provide them to you. > > - restrict localizations from using patch objects (it looks like this > is the case in the latest drafts). > > [ML] Sorry if I miss the meaning of this. What should be the alternative > mechanism to represent localizations without using the "localizations" > property. My apologies. I meant to convey that I believe this is no longer an issue. > > In line with the use of int/loc in RFC5733, we could use the same types for > both localizations and localized objects (e.g. we can add two addresses to > the "addresses" map) but we'd loose the information about the localization > language. I agree. Let's not do that. Hopefully the examples I provide will be better. > - clarity on hybrid address types (found in 5733 but also in other > registry models) > > [ML] Can you please clarify which kind of hybrid address types you meant ? Hybrid types are where parts of the address are structured and other parts are not. For example, locality and country may be structured but the rest of the address is not. > > - make signaling survive redirects > > [ML] It seems to me that the WG hasn't yet taken a final position on this, > discussion is still ongoing. So, at least for this version, I retained the > jscard query parameter. I am not willing to compromise on this especially as there is a workable solution. Any IETF authored RDAP extension MUST be compatible with the current RDAP ecosystem in its intended usage. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
