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<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.
[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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
