Re: [regext] New Version Notification for draft-ietf-regext-rdap-jscontact-17.txt

[Mario Loffredo <[e-mail]>]

Hi Andy,

thanks for your reply.

Again my comments inline.

Il 11/12/2023 22:41, Andrew Newton ha scritto:
> On Fri, Dec 8, 2023 at 3:57 AM Mario Loffredo<[e-mail]>  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.
[ML2] Think that, similarly to what is required by gTLD RDAP Response 
Profile (Section 1.1), we should mandate some properties and let servers 
be free to output additional JSContact properties.
>> - 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.

[ML2] There is nothing stating that the region address component must be 
a code.  It could be a code or not depending on how servers have set the 
region component of the jCard adr element thus far.

Besides, examples are not normative.

Hence, can't see how a reader can derive that.

Anyway, if it could be helpful, I can change the example.

>
>> - 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.
[ML2] OK
>
>> - 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.

[M2] Sorry but I don't catch this. If you talk about address parts, it 
means that you have already structured the address. An unstructured 
address is a text where you can't distinguish the single parts.

With respect to the address defined by RFC5733, the only part that is 
further structured is the street information.

Likewise, you can have multiple "name" address components in JSContact.

>
>> - 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.

[ML2] Think that signaling the request for the JSContact format is a 
minor issue. Would cost nothing to switch to the use of the Accept 
header but until we'll  reach consensus on this topic, other solutions 
are potentially acceptable including using a dedicated parameter or the 
versioning parameter.


Best,

Mario

>
> -andy

-- 
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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo