Hi all,
this new version partially addresses the feedback from Andy.
Please Andy and Tom find below a detailed reply to what you think that
JSContact profile for RDAP should include:.
- only express the items in SimpleContact
[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.
- 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.
- 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 ?
- 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.
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.
- restricting to JSContact 1.0.
[ML] Done
- clarity around JSContact links vs RDAP links
[ML] Have specified what JSContact links are for.
- define a more concrete scheme on sequenced IDs (and some examples)
[ML] Have further specified the any unregistered map key should follow a
pre-defined scheme.
- 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 ?
- 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.
Best,
Mario
-------- Messaggio Inoltrato --------
Oggetto: New Version Notification for
draft-ietf-regext-rdap-jscontact-17.txt
Data: Thu, 07 Dec 2023 23:54:07 -0800
Mittente: internet-dra...@ietf.org
A: Gavin Brown <gavin.br...@centralnic.com>, Mario Loffredo
<mario.loffr...@iit.cnr.it>
A new version of Internet-Draft draft-ietf-regext-rdap-jscontact-17.txt has
been successfully submitted by Mario Loffredo and posted to the
IETF repository.
Name: draft-ietf-regext-rdap-jscontact
Revision: 17
Title: Using JSContact in Registration Data Access Protocol (RDAP) JSON
Responses
Date: 2023-12-07
Group: regext
Pages: 26
URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-jscontact-17.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
HTMLized:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-jscontact
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-jscontact-17
Abstract:
This document describes an RDAP extension which represents entity
contact information in JSON responses using JSContact.
The IETF Secretariat
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
