Hi Andrew,
The new draft goes in the right direction, but for me there are still
few elements, that seem to be too complex for the purpose.
For all fields there is an assumed plurality with lists of values, where
theoretically the only differentiator should be the localization,
however actually the data structure does not exclude that there are
several values with the same localization or without any localization,
which might be confusing and also requires a complex processing by the
clients to always iterate the whole list in order to find out if there
is a certain localization present in the response.
Lists have still the issue of addressing the list elements with JSON
Pointers in redaction process.
As localization is a specific use case and would used on a need basis,
the case of single value being the main use-case, I would rather see the
values to be singular international value, with a localization being a
separate optional dictionary.
Using the example from 2.8 of a draft it would be something like this:
{
"individualName": "Yomada Taro",
"individualNameLoc": {
"ja": "山田太郎"
}
}
This approach allows a very compact representation if there is no
localization provided, and also a deterministic data structure if the
localization is necessary. It matches also EPP model in RFC 5733, where
actually max 2 postalInfo objects are allowed, one in internationalized
and one in local version.
An access to the localization can be also very easily be implemented by
the clients by looking up if the "Loc" key is present and then by
dictionary lookup of the needed localization.
I also suggest to stick to the field names and structure as defined in
RFC 5733, rather than defining new names or partially reusing existing
ones..
addr instead of postalAddress
streets instead of address
postalInfo as a wrapping object etc.
Example of complete simple contact (without localization):
{
"objectClassName" : "entity",
"handle":"XXXX",
"sc_data": {
"kind" : "individual",
"postalInfo": {
"individualName" : "Yomada Taro",
"roleName" : "Registration Services Help Desk",
"organizationName" : "ACME",
"addr" : {
"streets" : [
"Sunny Mansion #203",
"4-7 Hommachi 2-choume",
"Shibuya-ku, TOKYO 150-2345"
],
"cc" : "JP-13",
"pc" : "150-2345"
}
},
"email" :"yamada.t...@example.net",
"voice" : ["+81(03) 1234-5678"],
"fax:" : ["tel:+810312345679"],
"webContacts" : ["https://example.net/contact-me";]
}
...
}
Kind Regards,
Pawel
Am 31.08.23 um 12:02 schrieb Andrew Newton:
Hi all,
We have posted an update to Simple Contact. Here are the summary of the changes:
* removed structured names
* removed structured addresses
* fixed ISO-3166-2 usage
* removed the "masked" property
* updated the example
* added a section on linking to vcard / jcard / jscontact
Overall, this simplifies the draft significantly, which was the
overall feedback from IETF 117.
-andy
---------- Forwarded message ---------
From:<internet-dra...@ietf.org>
Date: Thu, Aug 31, 2023 at 5:56 AM
Subject: New Version Notification for
draft-newton-regext-rdap-simple-contact-01.txt
To: Andy Newton<a...@hxr.us>, Tom Harrison<t...@apnic.net>
A new version of Internet-Draft draft-newton-regext-rdap-simple-contact-01.txt
has been successfully submitted by Andy Newton and posted to the
IETF repository.
Name: draft-newton-regext-rdap-simple-contact
Revision: 01
Title: RDAP Simple Contact
Date: 2023-08-31
Group: Individual Submission
Pages: 11
URL:https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-01.txt
Status:https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/
HTML:https://www.ietf.org/archive/id/draft-newton-regext-rdap-simple-contact-01.html
HTMLized:https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-simple-contact
Diff:https://author-tools.ietf.org/iddiff?url2=draft-newton-regext-rdap-simple-contact-01
Abstract:
This document describes an extension to the Registry Data Access
Protocol for entity contact data using basic JSON values, objects,
and arrays. The data model defined by this document is purposefully
limited to the data in-use by Internet Number Registries and Domain
Name Registries and does not attempt to model the full data-set that
can be expressed with other contact models such as jCard or
JSContact.
The IETF Secretariat
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Pawel Kowalik
Head of Product Management
--
DENIC eG, Theodor-Stern-Kai 1, 60596 Frankfurt am Main, GERMANY
E-Mail:pawel.kowa...@denic.de, Fon: +49 69 27235-105, Fax: -235
https://www.denic.de
Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Thomas Keller, Martin Küchenthal, Andreas Musielak, Sebastian Röthler
Vorsitzender des Aufsichtsrats: Daniel Rink
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am
Main
Allgemeiner Hinweis zur Erfüllung unserer Informationspflichten gemäß Art. 13, Art. 14 DS-GVO: Informationen zur Verarbeitung personenbezogener Daten durch DENIC finden Sie unterhttps://www.denic.de/datenverarbeitung-allgemein/
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
